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ABSTRACT 


Software maintenance costs in Naval Aviation Operational 
Flight Programs (OFP) are very high and are projected to 
climb higher in the future. Maint2nance costs are high due 
to poor initial design, limited programmer and system 
resources, poor documentation, th2 conditions under which 


the OFP must operate and meme aicticulty involved in 


performing meaningful flight software tests. The primary 
factors which produce the stated problems wit aviation 
software systems are discussed. [The maintenanc2 phase of 


the software lifecycle model proposed for standard applica- 
tion software systems is contrasted with that for real tine, 
embedded, aviation software systems. A limited set of soft- 
ware tools and methodologies which area currently available 
and would greatly aid the system engineers tasked with OFP 
Maintenance is proposed. These tools and a¢ethodologies 
center on two areas of flight software maintenance; documen- 
tation and testing. The thesis concludes with recommenda- 
tions for future aviation flight software systems. 
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A. THE PROBLEM 


Software maintenance in Naval Aviation Operational 
Flight Programs (OFP) has become very difficult and costly. 
Costs will continue to rise as new weapon systems and 
mission requirements are integrated into the various opera- 
tional aviation platforms. Changes which reflect hardware 
improvements, mission changes, or improved algorithms are 
time consuming and can lead to long delays in delivery of 
the updated systen. Software Maintenance problems 
concerning the OFP are compounded by the environment in 
which the OFP must operate. This operational environment is 
areal time, limited hardware, limited support resources, 
and very tightly time constrained. The original design of 
thea OFP itself was often poor and little documentation is 
available to the maintenance tean. The OFP is written in 
either assembly language or avery low level pregramming 
language. Changes are made under a strict time table. 
Before any redesign or implementation of a change to an OFP 
may begin, a large effort must be expended to fully under- 
stand the OFP and the impact the proposed change may have on 
the entire program. Testing is a time critical task which 
consumes a Significant amount of maintenance resources. 

The maintenance effort is further complicated by a lack 
of trained system personnel. Personnel turnover at the 
software maintenance activities has been approximately ten 
percent per year. System programmers take on average three 
years to train before they able to be assigned the inplemen- 
tation of a significant change ¢5 an OFP. During this 


period the system programmer may be able +5 accomplish 
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little useful work for the maintenance activity. Due to ths 
generally poor documentation and the complex code of most 
OFPs there are only a handful of pesple who fully understand 
a particular OFP. Less of these k3y personnel would result 
in a severe reduction in the capability of the softwares 
Maintenance activity to continue at acceptable production 
rates. There is no improvement in the availablity of compe- 
tent system personnel predicted in the near future. 

Due to the unique problems presented to maintenance 
activities by the characteristics of aviation software, 
Maintenance costs are very significant. Fiscal 1984 oper- 
ating buget for maintenance of six aircraft OFPS at Naval 
Weapons Center, China Lake, California, is over 16 million 
dollars. This figure, while seemingly high, represents only 
75 percent of the regquested budget. Resources are? limited 
and the situation is not likely to improve. Several major 
proposed solutions have been suggested to improve the 
productivity andthe quality of th2 maintenance effort. 
These suggestions range from complicated software 
development/maintenance environments to complete rewrites of 
the flight software itself. Budget limitations will prevent 
any of these major proposals beiag realized in the near 
future. 


Be. THESIS OUTLINE 


This thesis focuses con the two areas where rapid 
improvement in the maintenance effort seems possible; docu- 
mentation and testing. A set of software tools and method- 
Ologies which are? currently available and which would have a 
Significant impact on these problem areas are outlined. The 
software tcols represent an affordable strategy for the 
maintenance activities to improve the maintenance of current 
flight software systems. 
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C. THESIS ORGANIZATION 


The remaining chapters are organized in the following 
manner. A scenario tracing the development and maintenance 
of an operational aircraft system, the A-6 Intruder OFP, is 
presented in Chapter Two. A detailed background of the 
aviation software maintenance problem is given. Chapter 
Three gives 2 brief discussion of a lifecycle model for 
aviation software maintenance in conparision with a standard 
application program lifecycle model. Software tools are 
defined and discussed. Unfeasiblé solutions are explored. 
Chapter Four discusses software maintenance/development 
environments. A software development environment which is 
in use by the Naval Air Development Center, (NADC), 
Warminster, Pennsylvania, is discussed. A set of tools and 
methodologies which center on two ara2as of OFP maintenance 
and are felt to have the greatest inpact on the productivity 
and quality of OFP maintenance are outlined in the nex* two 
chapters. In Chapter Five the first of these areas, docu- 
mentation, is discussed. Chapter Six covers the second 
areas, OFP testing. The thesis concludes with suggestions 
for future development of OFPs. 


D. RESEARCH METHODOLOGIES 


(D 


1. Literatur 


Manual and automated searches of the literature 
produced a limited amount 8 = Siiiigieainly-trapfepol concerning 
embedded, real time computer systems. Less was found on 
maintenance of the scftware used in these systems. An auto- 
mated search 29f government research topics dating back six 
years using maintenance, real tim? and embedded systems as 
keywords produced an impressive work summary. Upon closer 
examination, most research listed was not directly appli- 


cable to the 2amphasis of this thesis. 
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Noteworthy work dealing specifically with a Navy 
eaemteal aircraft (A=-7 light attack) OFP redesign has been 
ongoing under the direction of the Naval Research Léeboratory 
(Ref. 1]. In this study, not yet somplete, the OFP for the 
A-7 was redesigned using software angineering techniques of 
modularity, POeorMaAtlone hadeng, formal specification, 
abstract interfaces, and cooperating sequential processes. 
The study is at the pcint that testing both in ground sinu- 


lators and flight tests is ready +5 commence. It will not 
be known if the recoded OFP will perform as reyzuired until 
these tests are complete. The study offers interesting 


insights into the preblems associated with flight software 
systems as they are now designed. 

Definitions of the critical concepts »f software 
Maintenance, software environments, and the software life- 
cycle are readily available in the literature. Lientz and 
Swanson {Ref. 2] contains an excellent definition of process 
of software Maintenance in large application program 
systems. Fj2eldstan, Hamlen, Bristow and Van Horn provided 
further definitions used for software maintenance [Ref. 3], 
(Ref. 5j, [ Ref. 4]. Guidance in tae area of software envi- 
ronments was found in articles by Howden [Ref. 6], Bristow 
(Ref. 4], and Wasserman [Ref. 7]. Also the Naval Air 
Development Center provided an interesting discussicn of 
their development/maintenance environment, FASP (Facility 
for Automated Software Production) [Ref. 8]. The model for 
the software lifecycle was developed from Boehm [ Ref. 9]. 
The maintenance lifecycle was taken from Parikh and 
Zveginitov {Ref. 10]. The definitiosa of a software tool was 
taken from work conducted by the National Bureau of 
Standards (NBS) [{Ref. 11}. 


13 





2. Laboratory Vists 


A wealth of infsrmation and ideas was gathered 
during ‘rips by the author to the primary Navy Flight 
Software Activities on the West Coast, Naval Weapons Center 
(NWC), China Lake, California and Pacific Missile Test 
Center (PMTC), Point Mugu, California. The persennel who 
must daily face the unenviable task of performing the main- 
tenance on the flight software for all of the Navy attack 
and fighter aircraft were able to give detailed descriptions 
of their problems and suggestions for improvements. A tour 
of the facilities at both activities helped the author to 
gage the extent of resources available. 

A conference attended by rcepresentatives from all 
three Navy Flight Software Labs ani a group of researchers 
from various academic communities was held 5-7 IJctober 1983 
at the Naval Postgraduate School. Each Software Lab was 
given the opportunity to present waat they felt were their 
everyday problems in dealing with flight software mainte- 
nance and their ideas for future r3search. The conferencs 
turned out to be both stimulating and an excellent source of 
information. 
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II. BACKGROUND 


A. INTRODUCTION 


This chapter traces the developmant and current mainte- 
nance of a typical mature flight software system, the A-6E. 
The primary Navy software maintenance activities are identi- 
fied. The chapter concludes with discussion of the unique 
problems associated with real time, embedded aviation soft- 


ware systems. 


Be. A-6E FLIGHT SOFTWARE HISTORY 


The A-6 Intruder is an all weather, carrier based jet 
powered aetack aircraft built by Grumman Aerospace 
Corporation, Long Island, New York. Its primary mission 


definition is the accurate delivery of sizeable ordinance 
loads and close air support to ground units under all 
weather conditions. Since its initial design, it has taken 
On Other roles as a carrier based tanker, electronic warfare 
platform and delivery vehicle for the Harpoon antiship 
cruise missile. Many new weapon and sensor systems have 
been added to the aircraft since initial production. These 
include laser guided munitions, H2at Seeking Antiradation 
Missile (HARM), Forward Looking Infrared Sighting System 
(FLIR), and the Harpoon Missile. It is capable of carrying 
both nuclear and conventional weapons. It is a subsonic 
aircraft operated by the Navy and the Marine Corps from both 
land and aircraft carrier based squadrons. The attack 
configuration of the aircraft is manned by a two man crew, 
pilot and bombadier/navigator (B/N). The aircraft was first 
flown in 1959 and even though the production line for the 
A-6 has been closed it is planned to have an operational 


lifespan well beyond the year 2000. 
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The aircraft has onboard a single, CP3 computer with 32k 
words of memory. The computer takes part in processing data 
that is involved in nearly every aspect of the operational 
Sretieace aircraf*. Navigation, weapon system management, 
weapon release solutions, radar input processing, and elec- 
tronic warfare functions are all processed in sone manner by 
the onboard flight computer. Data -is input from several 
areas of the aircraft, processed and continuously displayed 
to the pilot and B/N. The computer is not necessary to fly 
the aircraft but without it the A-6 becomss essentially a 
jet powered World War Two era bomber. All major changes in 
weapon capabilty and mission assignment have to be in some 
Manner incorporated into the hardwar2 and software carried 
onboard. The Operational Flight Program (OFP) is the soft- 
ware loaded into the random access memory of the onboard 
alrcraf+ computer that processes the various input and 
display functions. 

Grumman Aerospace was responsible for the initial devel- 
opment, coding, integration and testing of the OFP. After 
acceptance of the aircraft for fleat operations, Grumman was 
contracted to perform ali software maintenance on the OFP. 
This maintenance consists of removing errors found in the 
OFP and the incorporation of enhancements to the aircraft 
system into the flight software. Any change in mission 
definiticr for the aircraft must also be reflected in the 
OFP. Grumman held the contract for maintenance until 1978, 
when Naval Weapons Center (NWC), China Lake, California was 
tasked responsibility for all maintenance functions of the 
OFP. Currently most actual redesign, coding and testing of 
updates to the OFP are performed by perscnnel assigned to 
NWC; some work is contracted out, primarily to Srumman. 

Entire OFP updates are sent to operational squadrons 
approximately once every year and a half. Only safety of 


flight or severe mission reducing software errors are given 
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immediate attention between scheduled OFP updates. There is 
a method provided for squadrons t > submit desired changes 
and report OFP operating problems to NWC. A formal review 
of desired changes to the OFP is conducted by the Navy 
yearly with squadron and software maintenance personnel in 
attendance. 

There are many more enhancements desired by the opera- 
tional squadrons than are able to be funded for incorpora- 
tion into future OFP updates. Some enhancements are not 
able to be adopted due to the nature of the computer systen 
itself. The system is hardware limited. The OFP itself 
fills all available memory of the onboard computer. Ma jor 
changes are possible only by degraiing another mission area 
or by increasing computer performance. 


C. WAVY SOFTWARE ACTIVITIES 


Outlined above is the history of one Navy tactical 
aircraft and its flight software systen. All other Navy 
aircraft have a Similar history concerning OFP development 
and current maintenance. There are three primary Navy 
Flight Software activities. Naval Air Development Center 
(NADC), Warminister, Pennsylvania, 1s responsible for P-3C, 
S-3A, and LAMPS Antisubmarine mission aircraft software. 
Pacific Missle Test Center (PMTC), Point Mugu, California 
performs maintenance on the F-14A Fighter, EA-6B Electronic 
Warfare platform, and various missl2 system software. Naval 
Weapons Center (NWC), China Lake, California, in addition to 
the A-6E, has responsibility for the FA-18 Fighter/Attack, 
A-4M, AV-8B, A-7E, and UH1-J attack aircraft OFP mainte- 
mance. In all cases primary OFP development was done by the 
prime system contractor and maintenance of the software was 
picked up at a later date by one of the software activities 
listed above. 
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D. AVIATION SOFTWARE MAINTENANCE PROBLEMS 


In the following sections the unique problems which 
render flight software in real tine, embedded systems so 
difficult and costly to maintain are outlined and dicussed. 
Nearly all areas covered are unique to flight software and 
are in addition to the normal difficulties encountered in 
standard application program maintenance. 


1. Platform 


In evary case the Operational Flight Programs are 
run on computer systems carried onboard high performance 
face ical aircraft. Space for hardware and support systems 
is limited. Primary importance is placed on aircraft weapon 
load and endurance capabilities. The fact that most Navy 
tactical aircraft are operated from aircraft carriers 
further defines and shapes the physical design of the 
aircraft. Operating an aircraft at sea subjects the 
airframe and internal components to severe stress during 
catapult launches and arrested landings. Instialdesign of 
the flight hardware system is often constrained within phys- 
ical space, e2lectrical power, and air conditioning support 
limitations before the hardware is selected. Once the hard- 
ware has been selected, the software is designed within 


hardware and mission requirements of the aircraft. 


2. Aircraft Lifespan 


When the A-6 waS originally designed in the late 
1950's the aircraft was néver envisioned to have a lifespan 
until the end of the century. The lifespan of the aircraft 
will approach forty-five years. That is equivalent toa 
World War Two aircraft being flown today ina front line 
squadron. The flight software and the ability to change it 


io reflect new ai nenan © Capabilities and nission 
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requirements allows the aircraft to remain viable for such a 
previously unheard of length of time. Aircraft are very 
expensive and as higher performancs demands are placed on 
the newly designed airframe and tactical systems the expense 
will grow. The high development and purchase cost forces 
the Defense Department into a position in which the aircraft 
are utilized as longas feasible. This posture on the 
utilization of these aircraft well beyond their criginal 
designed lifespan has several affects on the flight soft- 
ware. Mission requirements and weapon systems which were 
never contemplated in the original aircraft and flight 
computer design are being incorporated into the aircraft 
system years later. The hardware waich very well might have 
besn state of the art during the design of the system can 
quickly become the limiting factor as major changes «*o the 
OFP are requested and implemented. Changes to the hardware 
is not an easy task and is more expensive than the high 
software maintenance costs. In th? years since its initial 
design and introduction to the flest the A-6 has undergone 
one major computer hardware update, while the software is 
undergoing constant review and change. 


3. Independent Activities 


Se aa —l aE ae 


High performance aircraft have a large number of 
very independent devices which must operate in order for the 
aircraft to perform itS mission properly. These devices 
include sensors measuring various flight parameters such as 
altitude, air speed and angle of attack. Radar, infrared 
Sijmemng, electronic warfare and weapon guidance systems, 
are among the many devices that flight computer systems must 
also react to. Input from the aircrew must be incorporated 
into the flight system processing as well. Interfacing 
these devices and inputs is a compiicated task. This inter- 
face impacts greatly on the software engineer attempting to 
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modify a flight software systen. Not only must he under- 
stand the program itself, but he also must understand the 
interfaces and the affect a modification will have on these 
interfaces. This problem is prevalent enough that managers 
of both Navy software activities that were visited expressed 
a need for system engineers rather than strict computer 
software engineers. It was felt that the aircreft systems 
are complicated enough that it is easier to train a systems 
engineer to program rather than train the programmer to be 
an aircraft system engineer. 


4. Concurrent Activities 





Not only are there large nunbers of activities oper- 
ating independently, but these activities are also concur- 
rent in their operation. All of ths interfaces with sensors 
and data input are constantly updated so the program can 
perform as required. Timing considarations in the update of 
Enese activities in critical. Input from the flight crew 
which is bursty in nature must b2 processed so that it is 
handled in a timely manner and does not degrade the 
remaining processing. Display of required information for 
the flight crew must be constantly updated. The display 
must be accurate and in real time. 


5. Real Tine 


High performance tactical 2ircraft operate in very 
hostile conditions. Complicating the software problem is 
the high speed that the aircraft flys while in the hostile 
environment in order to enhance its survivability. Ties 
mandates that the processing of data in the flight computer 
system must be done in a real time manner. The definition 
of real time for flight systems does not equate to the defi- 
nition for a banking database systen. Single CPU cycles can 
become paramount. An aircraft traveling at 450 knots at two 
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hundred feet in altitude requires that updates from the 
onboard computer be timely indeed. A delay of milliseconds 
can cause the delivered weapon to niss the target entirely 
or loss of the aircraft itself. Every change incorporated 
must consider every possible affect on the timing 
constraints of the progran. 


6. Reliability and Recoverability 


The degradation of one aspect of the flight software 
system must not allow the loss of the aircraft. The 2xpense 
of the aircraft, aircrew and weapons requires high reli- 
ability in the flight software system. The system must also 
be able to recover from loss of input data resulting fron 
battle damage and ccntinue to operat? in a degraded mode. 
The software must be protected against hardware failures as 
well. Failure of the entire system must only occur when the 
aircraft is damaged to the point of crew abandonment. 
Purther the system cannot tolerate a requirement to restart 
the program due to a syst2m fault interrupt or program crash 
caused by a software error. 


7. Program Complexity 





Due t> the timing constraints placed on the OFPs, 
mos< are coded in either assembly language or ae very low 
level programming language such as CMS~-2 (P-3C) or Metaplan 
(F-14). The ability to perform various software engineering 
programming techniques commonly used in higher level 
languages is lost. The original design of the program is 
often not modular. The lack of modularity coupled with the 
ad hoc fashion in which chanaes have been made through the 
years has left the OFP code extremely complex. A great deal 
of effort is required to merely comprehend the OFP before 
changes are even designed much less implemented. The impact 


of a change to a particular piece of OFP code nay have an 
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impact on an entirely different unrelated section cf code. 
A case cited during one of the laboratory visits concerned a 
minor change to a section of code which dealt with naviga- 
tion of the aircraft resulting in the inability to release 
any weapons. The results of chang2s to the code is poorly 
understood until the code is actually changed and testing of 
the revised OFP is begun. As has been well documented in 
the literatura this avery expensive time to discover rede2- 
sign errors. 

The design of newer systems such as the FA-18 
Fighter/Attack aircraft will show improvements in the ease 
of conducting software maintenance on the flight software. 
The A-6E has five identifiable nodules which have been 
implemented during the last five ysars of maintenance by 
NWC, the FA-18 OFP which was written by Hughes Corporation 
of Long Beach, California shows a marked improvement in 
modularity with over one hundred idantifiable modules. The 
situation seems to have improved much over the twenty years 
between the design of the A-6 and the FA~-18. The FA-18 OFP 
is, however, coded in assembly langauge due to real time 
requirements of the flight software system. 


All Navy software activities tasked with OFP mainte- 
nance had one common complaint. That complaint centers 
around the lack of useful documentation received from the 
original designer of the flight software. While the entire 
subject of documentation is subject to debate as to its 
proper form, what is commonly turn3d over to the Navy from 
the development contractor is seversly lacking. Even in the 
newest systems (FA-18 and AV-3B) the documentation 
received from the contractor has aot been as extensive as 
the maintenance acitivity desires. Usually a program 
listing is the primary documentation received. Maintenance 
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activities find themselves not having accurate perfcrmance 
requirement documents on the aircraft itself or specifica- 
tion requirements for the OFP. Documentation carried today 
has largely been generated by the naintenance activity. 

A problem related to documentation was identified by 
Neetz, [{Ref. 12], of PMITC concerning the difficulty of the 
maintenance programmer in understanding the desired change 
to an OFP submitted by fleet personnel. The information 
contained in nost deficiency reports was often found to be 
limited and this slowed the problem identification process. 
He also found that the managers felt that feedback from the 
fleet was adequate while the technical engineers felt it was 
not adequate. 


9. Training 


As stated earlier each software activity faces high 
personnel turnover. Many studi2s have shown that the 
required numbers of computer capable system engineers are 
not being produced. Competition with industry is’ keen. 
After asystem engineer is trained adequately he may be 
offered a position with the contractor of the system he is 
trained on at a hefty salary increase. Training of a new 
system engine2r is an extremely slow and difficult process. 
Adding to the problem is that often while this training 
period is ongoing this engineer may not be directly involved 
Bae any productive work. Since the numbers of qualified 
personnel is not expected to grow quickly and there is no 
PEadening institute for training engineers on specific 
aircraft systems, all training must continue to be done 


internally. 


10. Hardware Limitations 





As stated earlier, the hardware design of the flight 


computer systems was often consider2d state of the art when 
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first installed in the aircraft. As the aircraft ages and 
more capabilities are added to the aircraft, +he hardware 
can quickly become the limiting factor in implementing 
enhancements to the OFP. The A-6 was designd with 16K of 
avallable RAM. Reserve memory was quickly allocated to new 
functions implemented in the OFP within the first few years 
of fleet operations. A major upgrade to 32K was accon- 
plished in 1968, this quickly met with the same fate as the 
Original 16K implementation. The JFP of many Navy aircraft 


have zero percent memory and throughput reserve. This 
factor leads to further complication of the OFP code when 
changes are made. Additions of particularly large changes 


to OFP cede ma y require that certain functions of the OFP be 
either degraded or dropped altogether. Simply adding larger 
amounts of reserve memory has not b2en the answer due to the 
difficulties in making hardware changes to the aircraft 
izselt. Also there are many more enhancements awaiting 
implementation that would quickly be incorporated if memory 
were made available. 


11. Aircraft Populations 


One problem facing the software maintenance activi- 
ties as a whole is the limited naumber of aircraft of a 
particular type being flown. At any given time there are 
approximately 200 A-6 aircraft assigned t9 operational 
squadrons. The number of computers and flight programs 
represented by that number is not large enough to warrant 
large expenditures fer major software redesigns and large 
Support environments which would lower maintenance costs. 
Aircraft are 2xpected to be fully supported after production 
lines have closed and the number of aircraft and funding 
support is dropping. The A-7 production line has closed but 
the largest change to its OFP was recently conducted by NWC 
when the HARM system waS incorporated into the aircraft 


inventory. 
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12. Human Factors 


Anoth2r obstacle facing th= maintenanc2 programmer 
dealing with aviation programs is the human factors associ- 
ated with input and display of data for the flight crew. 
Human factors is defined as the functional «ask area which 
is concerned with the aspects of human performance that 
affect or are affected by the software [Ref. 13]. The area 
to which this definition refers falls primarily under the 
input and display of data to the flightcrew. Changes to the 
program which affect display are 2specially critical. The 
display must be presented in such 43 Manner that it does not 
require undue effort for the flight crew +o comprehend it. 
Little is understood inthis field of computer science. 
Research is currently being conducted at PMTC dealing 
specifically with human factors as they relate to flight 
programs. Programmers implementing changes t9 an OFP must 
constantly keep in mind the affect of their change oon any 
display data. Guidelines for th2 affect on the flight 
computer operators is not based on scientific fact rather it 


is based on operator feedback. 
ioeeiaelo ta Dyes ta ndards 


Currently all software maintenance activities 
operate under several Military Standards (Mil-Std) waite h 
guide the development and maintenance of the programs they 
cover. Primary in importance to tha flight software systems 
is Military Standard 1679A (February 1983) which ccvers 
Weapon Systen Software Development. Unfortunately this 
standard while good in its intent does not address the real 
world situations of OFP development and maintenance. 
Several of the active OFPs were written ten to fifteen years 
prior to Mil-Std 1679 first being issued (1978). Concepts 
covered by Mil-Std 1679 were not applicable when these older 
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OFPs were designed. Mil-Std 1679A requires the use of a 
high level programming language in all weapon systems. As 
has keen mentioned earlier, it is not possible to code 
current OFPs in a high level language due tc timing 
constraints. NWC personnel have expressed some concern over 
the requirements outlined in Mil-Sti 1679 and the difficul- 
ties in following it on an OFP as complex as the A-6's has 
become. PMTC personnel have no r3al complaints about it. 
But it should be remembered that they are working on some- 
what newer systems to which it can be more readily applied. 
A review of Mil-Std 1679 is contained in [Ref. 14]. 


14. Deadlines 


The software activities maintaining flight scftware 
On operational aircraft often find themselves facing severe 
deadline requirements. Safety of flight or primary mission 
degrading problems with the OFP ar2 processed on an imme- 
diate basis requiring the possibility that all other OFDP 
maintenance tasks be dropped. If the redesign of the OFP is 
not properly done and the error is not discovered until late 
in testing phases, nearly the entire process must be 
repeated and delays in OFP updates may be experienced. in 
order to meet strict deadlines sertain update features 
cannot be accomplished. This constant time deadline influ- 
neces the performance of the maintenance effort throughout 
its cycle. 


Before a revised OFP can be considered safe to 
flight test extensive ground testing is completed. This 
testing requires massive support facilities in the form of 
flight simulators. The target aircraft computer is loaded 
with the revised OFP. The support facilities suuround and 
interface with the target system suppling input data to 
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exercise the OFP. The support facility measures the 
performance of the OFP under the simulated fligh= condi- 
tions. Because of the complexity of the OFP code, poor 
documentation, and high reliability required, testing is the 
most expensive of the operations performed on the OFP during 
a maintenance change. Little is known on the exact method 
to test the code to yield meaningful test rssults. The 
nature of the OFP code itself and the mission it must 
perform renders the testing of the code even more difficult 
than normal. 


16. Scope of Maintenance Changes 


Industrial application programs normally face a five 
percent per year code growth due to software maintenance. 
The maintenance of OFPsS produces something on the order of 
twenty five percent code change per OFP update. The shear 
amount cof cede required to make the changes during an update 
cycle contributes to the difficulty of the maintenance. 
After the completion of two to thre OFP updates the code 
may be significantly changed from the orginal program. 132 
not well documented, the high volune of maintenance changes 
will render the program almost unfathomable. A problen 
faced by the maintenance personnel is that the code has 
already gone through several updates prior to being turned 
over to the Navy. 


744 





III. MAINTENANCE IN NAVA 


A. INTRODUCTION 


The question of why software is the important product in 
aviation flight computer systems is addressed first. A 
general description of the softwar2 lifecycle and the main- 
tenance lifecycle as related to aviation systems is given. 
Proposed solutions to the flight software maintenance 
problem are given. The following iliefinitions are outlined: 
software tool, software maintenanca, lifecycle model, and 
Maintenance lifecycle model. 


Be WHY SOFTWARE? 


When first designed and built, real tine embedded 
computer systems had their functional capabilities primarily 
embodied in the electronics with software playing a minor 
Bone controlling ancillary functions. Demand on the 
performance of these systems requir2d that they be designed 
with a greater degree of inter-system communication between 
devices. This has caused the software of these systems to 
shift from a minor role to one where the system functional 
definition is in the software and the electronics are only a 
means of providing for execution. 

Boehm {Ref. 9], defines software as the entire set of 
programs, procedures and related documentation associated 
with a system. The Software Technology for Reliable Systems 
(STARS) Program Strategy Ha ndbook Pyssspaik addition: detani- 
tions, designs, testing materials and maintenance instruc- 
tions [Ref. 13]. Software is what controls the computer and 
allows it to accomplish so much. The hardware in the actual 
computer systems of the tactical aircraft undergoes few 
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Changes throughout the lifespan of the aircraft. Yet chs 
flight software system is expected to be constantly upgraded 
as additions and enhancements to the aircraft system are 
implemented. These changes are primarily reflected in 
software. 

The U.S. Air FPorce experienced a situation that illus- 
trates the case for software in embedded computer systems. 
F-111 tactical aircraft were operated in two basic models. 
In one, avionic systems were implamented in analog devices 
while in the other the same systams were implemented in 
digital devices. The Air Force was tasked to keep the capa- 
bilities of both models equal. Several changes to the 
systems were tracked and it was determined that changing the 
hardware implementations was roughly fifty times as costly 
as the software changes [Ref. 13]. The cost and time to 
design a software change is roughly equal in cost and time 
to design a hardware change. Hardware however, requires 
management of individual changes and physical copies of the 
new hardware be maintained. Software is much easier to copv 
on multiple tapes and gquickly load into the individual 
computers. The difficulties in implementing changes with 
hardware are evident when compared to implementing the same 
changes in software. | 

PMTC personnel point out the case of the F-14 as another 
example of why improvements to the aircraft computer system 
are best carried out in software. F-14 OFP changes are 
promulgated approximately every two years at a total cost of 
roughly two million dollars for each change development and 
implementation. There are approxinate2ly 400 F-14 4aircraft. 
Implementing the changed OFP in each aircraft consists of 
merely loading the new OFP tape into the aircraft computer 
system memory. The cost of a new OFP is approximately 5,000 
dollars per aircraft. Anyone exp2rienced in making equip- 
Ment alterations to military aircraft knows 5,000 dollars 
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wee by very little. When considered against the cost of 
an individual F-14 (@ $30 million) implementing flight 
computer system changes through software is very cheap. Ee 
all of the corrections and enhancements to the system had 
been made in hardware the costs would have been in the 
billions of dollars. 


C. SOFTWARE HAINTENANCE 


Fjeldstad and Hamlen define software maintenance +o be 
incorporaticn of changes to existing programs, using or 
modifying an sxisting approach or design then understanding 
and modifying or expanding existing program logic {Ref. 3]. 
Lientz and Swanson describe the primary types of maintenance 
(Ref. 2]. 


1. Corrective Maintenance: correction of errors intro- 
duced in the software through improper logic or coding 


errors. 

2 Adaptive Maintenance: Satisfaction of changes in 
precessing environment. EnpRe and oe OE ede ena 
often change. This case waS experienced with the A-6E 
system when the aircraft's navigational suite was 
upgraded. 


3. Perfective Maintenance: enhancement of the system for 
increased po suoeence and maintainability. This includes 
improvements to decumentation and recoding to improve 
progran Ee ec 2 RC: Again using the A-6E as an exanple, 
the aircraft was tasked to po eeue low level bombing fron 
two hundred feet vice five hundred feet. This change was 
induced to increase, weapon accuracy while also increasing 
aircraft survivability against heavily defended targets. 
This, improvement in the aircraft mission definition 
reguired extensive OFP software modification. 


Lientz and Swanson in [Ref. 2] offer the following 
Statistics on the allocation of maintenance time. Twenty 


percent of the maintenance effort involved corrective main- 


tenance. Adaptive maintenance accounted for twenty five 
percent. Perfective maintenance accounted for the rest of 
the tims at fifty five percent. Enhancements accounted for 


the largest share of ‘the perfective maintenance at forty 


nine percent of the total maintenance effort. These figures 
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were taken from a survey conducted of large data processing 
organizations. 

Results of an informal survey of NWC maintenance time 
yielded slightly different figures. Corrective maintenance 
of errors which are present from the last OFP update or 
earlier, only comprise five percent of the maintenance time. 
Adaptive maintenance is roughly the same as the Lientz find- 
ings at twenty percent. The larg2st share of the mainte- 
Nance time in OFPs resides in perfective maintenance. This 
involves mainly optimizing +the code and incorporation of 
enhancements to the aircraft system as a whole. 

Van Horn defines another form 9f software maintenance, 
that of restructuring, [Ref. 5]. Restructuring involves 
change to the internal structure of the program while rot 
changing the overall external behavior. This is interest- 
ingly a consideration for improvement to many of the older 
OPPs and was implemented by the Naval Research Laboratory 
feet. 1) for the A-7 OFP. 


D. SOFTWARE LIFECYCLE 


Figure 3.1 presents the staniard waterfall software 
lifecycle as seen in Boehm [Ref. 9]. This model represents 
the development of a standard larg® scale application soft- 
ware system. It is based on two assumptions: 

pack hase of the lifecycle is culminated by a verifi- 
eaees phase that attemptS to 2liminate errors in the 
Output of that phase. This 1s expected to be accon- 
plished prior to moving to the next phase. 


Dag terations Qt oo rane S: phase products are performed in 
the next succeeding p 


Each phase of the Boehm Lifacycle Model is briefly 


described below: 


A. Feasibility: Defining et pee ag SER ENe Deo posed SOtcS 


ware product. Is it feasib to be accomplished? And 
Will it be superior to the syst3m that it is proposed to 
replace? 
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Figure 3.1 Boehm Software Lifecycle Sodel. 
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B. Requirements: A validated specification of required 
functions, interfaces and performance aspects of the 
proposed system is generated. 


C. Design: The high level hardware-software architectural 
design, control Structur2 and aajor data structures for 
the system are outlined. 


Detailed Design: Complete verified specification of 
eo level deSign is produced. Precise algorithms, 
structures, interfaces and control structures are 
ned. Several refinement steps are involved as 
l of system is realized. 


rey) 


Op) Dre 
tH +O 
aH 
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- Code: The software portion of the gees is imple- 
ented in executable code. Testing of individual compo- 
ents begins. 


PBtt BmpuctO 


F..f[ntegration: The software product is made functional 
Sides Cup. Individual components are integrated into 
subassemblies and finally into the fee! software 
product. Initial errors are removed from software as 
they are identified. Program testing continues. 

G. Implenentations: The software-hardware system is 
Drought into initial operation. Testing is completed to 
determine 1£ the overall product meets design objectives. 
H. Maintenance: Error corrections are made t> the opera- 
tional program. Perfective and adaptive changes are 
accomplished as needed. 

ic: Phaseouts: A replacement system is designed and 
2 mplemented. 

The system is sequential in nature andthe start of any 
phase assumes the completion of the proceeding phase. The 
verification and validation part of each phase is defined as 
follows: 

Verification is the process by which the truth of corre- 
spondence between the software itself and its specifica- 
tion is assertained. | 
Validaticn establishes the fitness 9f the software system 
in carrying out its intended operational mission. 

Boehm further states that th2 lifecycle as proposed 
allows for ahigh degree of control in the configuration 
Management of the product. The manager is able at any given 
time in the development/maintenancs process to define the 
specific state of the project in concrete terms. 

Once a design strategy following the lifecycle model is 


implemented the project baselines can be established. 
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According to Boehm the three major advantages gained fron 
this baseline are: 
1. No changes are made to the system without agreement of 
all interested parties. 


Des Higher threshold for changes will stabilize the 
DrEOauct. 


3. The overall manager controls the configuration nanage- 
ment process. 


The lifecycle model as presented by Boehm is a well 
known and accepted model. The question remains just how 
well does the model comply with real life systems. When 
comparing this model to the development and maintenance 
lifecycle of a typical aviation software system it seems not 
to compare well at all. The current method of operation in 
OFP maintenance has the maintenanc2 activity stepping into 
the lifecycle model at the next t> the last phase. The 
software activities have in the past had little input into 
the software development process conducted by the prime 
system contractor. There is littl or no communication in 
the form of documentation when the software activity assumes 
responsibility for maintenance. The logic and design meth- 
odologies usei by the original designers are lost to th? 
maintenance personnel. The continuum of the lifecycle model 
as proposed by Boehm is lost when the Navy begins mainte- 
Mance Of the OFrP. 

Boehm also gives little mention of the maintenance phase 
itself in his discussion of the lifecycle model. Several 
studies have found that the maintenance phase of the life- 
cycle the most expensive. Estimates range from fifty to 
G€ighty percent of overall system costs are involved in soft- 
ware maintenance of a large application software systen 
(Ref. 2]. A U.S. Air Force study estimated that software 
costs during developemnt averagei $75 per instruction. 


During the maintenance of an operational system the software 
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costs increased to $4000 per instruction [Ref. 15}. This 
trend is reflected in aviation flight software systems as 
the lifespans for the aircraft they serve are extended. 


Ee MAINTENANCE LIFECYCLE 


The maintenance phase can be thought of as a lifecycle 
Within the cverall lifecycle. Incorporating enhancements to 
a system cr repairing errors not found during initial 
testing phases will involve a redssign effort similar in 
Many respects to the initial design of a system. Parikh and 
Zvegivtov { Ref. 10], review a maintenance process in the 
Opening comments to a chapter in their book on Software 
Maintenance. Figure 3.2 illustrates this process. This 
representation is based on changes being made to a fully 
operational system. Their simplified maintenance lifecycle 
is defined as follows: 

le Understand the Request: rhe user of the systen 

requests a change to an Te a erek be made by the 

Maintenance? ac mee his request is written in 42a 
aed ouge familar to the user. Ths maintenance programmer 
must understand the request and the current program prior 
to design of the change. 


2. Transform Request: Using a description of the existing 
and requested systems, the differences between the two 


are sought. The process. of désigning for the change 
involves reducing he differences between the existing 
and the new system. The existing system 1s revised to 


match the new systen. 


3. Specify Change: A Cut Line and Patch are, specified. 
The Cut Line is the section of code to be modified. The 
Patch is defined as the new cod2 to be implemented which 


reflects the new system within the Cut Line. (The selec- 
tion of tha Cut Line is difficult because it is selected 
to Minimize interaction between the existin system and 
the Patch. Lowering theses interaction wil reduce the 
Chances of damage to other sections of the program not 
necessarily related to the Cut_ Line. Modularity of the 

regram is a_ ke aid in selestion of the Cu Line. 


Program complexity is another issue which affects the 
interaction of the Patch once inserted within the Cut 
Line. 


4. Develop the Patch: The Patch is actually developed in 

a programming non eae uSing standard development techni- 

ques.  . The ultimate goal of the Patch is. the 

accomplishment of the requested change to the existin 

peoeces The Patch should be designed such that it wil 
it within the Cut Line. 
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Figure 3.2 Parikh and Zvwegivtov Maintenance Lifecycle. 
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9. Test: The change is installed and tested within the 
development environment. The Cut Line is tested for 
appropriate switching between thse existing functions and 
the new code. The impact of the new code to code outside 


of the Cut Line is identified. Regression testing is 
performed where needed. 


- ,Releas2?: Once tests are performed the updated systen 
iP installed and released. ae P y 


The model for the maintenance cycle presented by Parikh 
and Zvegivtov can be seen as a refinement of the overall 
lifecycle presented by Boehn. Its major concern is in the 
understanding of the request, relating that knowledge to the 
existing system and designing the sthange such that it will 
not degrade the updated system. Interaction is addressed 
more specifically. It is perhaps optimistic in assuming 
that the Patch can always be installed within the Cut Line. 
Also the selection of the Cut Line while difficult in a well 
designed program would seem nearly impossible in a complex 
software system. The rather difficult and extremely large 
area of testing is given a quick review in this model. The 
cycle assumes several characteristics of the existing 
program, such as proper design, adequate documentation and a 
well developed maintenance environnent. This may render 
this model somewhat Simplified for the embedded computer 
system. A model for <¢he aviation software lifecycle is 
presented next. 


F. AVIATION SOFTWARE MAINTENANCE LIFECYCLE 


The aviation development/maintenance lifecycle as 
presented in Figure 3.3 was taken from a slide presented by 
NHC personnel. Further discussion was held with maintenance 
personnel to determine how close th2 real maintenance effort 
parallels this definition. The model presented roughly 
follows the Boehm model. The aviation model is presented in 
greater detail. Each phase is well documented by required 


submissions of reports and specifications. Reviews, audits 
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Figure 3.3 OFP Development/Maintenance Lifecycle. 
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and walkthroughs are scheduled at several points of «he 
model. Table I defines the abbreviations used to represent 


the documentation and reviews shown in the model. 


TABLE I 
Aviation Lifecycle Terms 





<2 > eee ae ae a ee Eee eee 


Lifecycle Documentation 


Mission Element Need Statement. 

System Requirements Specification 
Program Performance Specification 
Interface Design Document one ; 
ee eh to OST ee Specification 
Program Design Specification (Final 
Data Base Design Document 

Program Package . 

Program Description Document 

Software Development Plan 

BO ALS ees Management Plan 

Quality Assurance Plan 

L: Computer Program [2st Plan _. ; 

: Computer Program [est Specification 

R: Computer Program [2st Procedures 

: Computer Program Test Report 


CR) adte te 602 (f} 


yUD Ur SOON WOUD Ut 
Hrihitirov Des ONNMnNMNsS 
66 66 a0 


QANAADAYH VO VIOH UNS 
rt) U2" ee 08 08 ee 


Reviews and Walkthroughs 


Mission Requirement Review 
System Requirements Review 

: Software kequirements Review 
Preliminary Design Review 
Critical Design Review 
Module Code Review 

: Formal Validaticno Readiness Review 
Uiebee Review Comaittee 
PFunecerond | econ ragirarseon Audit 
Physical Configuration Audit 
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The model as presented is well structured and well 
defined. Unfortunately the reality of what actually occurs 
during development of maintenance code may not be accurately 
represented by this’ model. There are several reasons for 
this. In many of the older flight systems the exact process 
of software maintenance was not precise and was difficult to 
define. Some of the documentations specified and reviews 


presented in the nodel are currently not being conducted in 
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every flight software systen. The model presented repre- 
sents a standard that several of the OFP maintenance <eams 
are attempting +o achieve. What is actually occuring is 
only partially represented by this nodel. 

Nearly all flight systems undergo few hardware changes 
throughout the lifecycle. The hardware branch sf the model 
only applies to new development of an entire flight systen 
or a major midlife modification. The year to year software 
Maintenance of the OFP has the software branch of the model 
taking on the most impact. New aiditions +o the hardware 
and complete changes are usually done with hardware already 
in use in cther systems. This also significantly reduces 
the amount of time spent in the hardware branch of the 
lifecycle. 

The integration phase of the aviation model represents 
primarily the integration of the old and new OFP code. The 
complexity of older system code makes this much more diffi- 
cult than the integration of the entire OFP with the systen 
hardware. Also code may be developed by paraliel develop- 
ment activities. Centractors are sften utilized to perform 
the generation of portions of maintenance code. Since these 
parallel redesign effcrts are usually conducted on different 
systems, conversion of the code developed outside may be 
required in order for it to be intsgrated and tested at the 
Navy software facility. 

One high level manager involved in the maintenance 
effort on one of the older OFPs told of the reluctance of 
the system engineers and programmers to adopt any standard 
mod2l for the maintenance process. They are used to doing 
it aocertain way that is comfortable to each indiviual 
programmer. A standard is difficult for them to accept. 
The stages are well documented. The reviews and walk- 
throughs require the programmer +5 spend a great deal of 


time preparing for then. One programmer conplained of 
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spending over twenty hours preparing for a review on a small 
secticn of OFP code which required one hour of time to 
recode. 

Even though it may not be exactly standardized for each 
Maintenance team, the model presented in Figure 3.3 presents 
a good general representaion of what each OFD undergoes at 


one time or another during development and maintenance. 


G. SOFTWARE TOOLS 


1. Definition 


Software tools are defined by the National Bureau of 
Standards [Ref. 11], as computer programs that aid in the 
specification, construction, testing, analysis, management, 
documentation and maintenance of other computer programs. 
Shooman divides these many MIinGcetons Into four broad 
catagories, [Ref. 16]. 

a. Program editing and storage 

b. Program processors and preproctessors 

Ge. Program configuration and control 

d. Testing and debugging process2s 
The purpose of a Software Tool is to aid the programmer in 
such a manner that productivity and the product quality are 
increased. They are designed to be used many times on 
several different projects within several different 
environments. 

In (Ref. 7] Wasserman gives the attributes of a 
useful ¢tccl as the fcllowing: 


signed 


(eae Songudaratyaco f ¢ 
Sort ry us diene 


for one prima 


Purpose: , The tool sho 
on Ca 
aon. 


uld be d 
= rrying out one well define 


2. Ease of Use: gle tool should not burden the user. The 
programmer shoul want to use the tool to increase his 
PEeOQGuCcrLVIty. 
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Sea soelf poe Uren Se The tool should not have large hard 
copy documentation but instead most documentation should 
be in the form of an interactive help facility. 
4. Consistency: Each tool should be consistent with the 
others of the environment in which pace are contained. 
The product of a tool used earlier in the lifecycle of 
the software should be able to be used by another tool 
used In a later phase. . To achieve this tools should 
interact through common interfaces. Tools within each 
environment conform to aset of standards so that fami- 
larity with one tccl will help in learning another tool. 
5. Adaptability: A tool. should ba able to adapted to some 
user desires. The tool should have several modes avail- 
able from a basic generic mode up through the full design 
Gampability of the tool. 
6. Local Intelligence: The tool is able to capture useful 
data from the. environment in which it is employed. 
Normally this is stored to a data base where it Bag) 
ion 


further eee for documentation and configura 
management purposes. 


2. Software Tool Usage 


There seems to exist a gensral agreement within the 
literature that well designed software tools are highly 
desirable. Precise tool definition and terminologies are 
not well defined. In [{Ref. 11], a taxonomy of software tool 
definitions and terminologies are standardized in order +o 
allow comparision amcng different tools. Software tools are 
large computer programs, which like any other programs, face 
the same development and maintenance problems. They are 
expensive to develop and may not always meet the original 
specificaticns. 

Other than expense there are several other reasons 
that software tools have not found wider use. Nassi 
(Ref. 17], lists several general catagories which have hind- 
ered the use of software tools. 


ae General Nature of Many Tools 


Some tools are very ganeral in their intended 
use and are not at all suitable in some specific systems 
without a large modification effort. To develop a specific 


tool for a specific application may not be worth the 
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development costs when compared to the savings it will 
generate. This is a common case for lack of tool use in the 
aviaticn software field. Some aircraft computer systen 
populations are low and do rot warrant the expensive that 
deve lopment of a tool for that particular OPP would entail. 


b. Learning Curve 


Programmers accustomed to working in a certain 


environment may find the pain of learning anew tool not 


moeuherhneir effort. Even if the programmer can be shown to 
benefit greatly from the use of anew tool, habit may make 
Pmoeaaept1on Of that tool difficult. A oetoo lL wheeh 1s 


particularly hard to use or learn is doomed to failure. 
Usability of the tool should be such that the programmer is 
not encumbered by its use. It should compliment the envi- 


ronment in which it is used , not fight it. 
Se functionality 


Peas tOOd~e1lS Met suutanle for a specfiic job it 
may create performance burdens on the system on which it is 
being used. The overhead created by its use should not be 
excessive. The tool should be reliable in that it may often 
be operating directly On user source files and the 


programmer must be able to trust in its use. 
d. Integration 


The integration within an environment should 
allow for the tool in use to communicate easily with other 
tools. The programmer will then be able to move smoothly 
back and forth between stages as needed without a great deal 
Sraof fort. 
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€. Td0l Usage by Software Activities 


Coupled with the reasons cited by Nassi for the 


limited use of software tools, the flight software mainte- 
mance activities face other problems. Funding to purchase 
the tools is not available. The software activities 


conducting maintenance on the OFPs io use a varirty of soft- 
ware tools. Most seem to be generated in house for specific 
purposes within the enviroment of a particular OFP. They 


are often not portable to another project. The use of more 
powerful off-the-shelf tools has also been hindered by 
several factors. The state of most OFPS currently would 


require extensive reconfiguration t> allow the use of these 
tools. The worst problem is the lack of documentation. 
Many tools developed by industry require a well designed, 
well documented program to work with. An example is the TRW 
developed software tool SREM (Software Requirements 
Engineering Methodology). SREM requires that documentation 
in the form of an adequate set of program requirements be 
available. Most OFPs do not have such documentation and 
thus cannot use SREM in the production of flight software 
cod2. 

The environment of the maintenance effort for 
the various OFPs differ from project to project. None of 
them seem to be able to suppert a set of tools which would 
cooperate and communicate during the maintenance process. 
The work required to set up the environment and program tc 
work with an off-the-shelf tool has been found in many cases 
to be excessive. Internal development of powerful tools is 
also time consuming and may not be feasible. 

The Av-8/A-4 test facilty at NWC conducted a 
survey of all software tools in use in their facility. The 
results are interesting and reflect the situation throughout 
most OFP maintenance and test facilities. Forty four 
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different tools were listed as in ase. Ninty five percent 
of the tools were developed internally by personnel assigned 
to the test facility. Twenty nine percent have the ability 
to communicate with one or more tools. Fifty percent of the 
tools had no support available. It is easy to see that this 
is a long way from the ideal situation many authors propose 
for automated tool usage. 

The maintenance activities find themselves 
unable to buy their way out of the OFP maintenance probien 
by designing or buying tools. Once a software system is 
accepted from the developer the original design and documen- 
tation may limit what the maintenance activity has available 
to improve the maintenance effort. 


H. PROPOSED SOLUTIONS 


Many solutions have been proposed to ease the software 
maintenance problem in common application systems. A 
Smaller list of solutions have bean proposed for embedded 
systems. Solutions range from the incorporation of good 
software engineering practices in the design of the software 
to the use of extensive programming environments throughout 
the lifecycle of the progran. Most of these solutions are 
viable and would help if they wera to be applied from the 
original design of the software. Several of the proposed 
solutions are outlined. The reasons for the nonuse of thess¢ 
solutions are also cited. 


1. OFP Rewrite 


Many of the flight software systems still in use 
were designed before many of the software engineering prac- 
tices that are today taken for granted were in common use. 
A complete rewrite of an OFP using these techniques has been 


suggested as a possible solution to the maintenance problem. 
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This was the idea behind the work of the Naval Research 
Laboratory [Ref. 1], in the recoding of the A-7 OFP. The 
use of the software engineering techniques of modularity, 
information hiding, formal specification, abstract inter- 
faces and cooperating sequential processes were used in the 
updated OFP as it was rewritten. It is hcped +hat these 
techniques will lead to lower maint2znance costs »f the OFP. 

An entire rewrite of the OFP offers several clear 
advantages. It is in fact considered the only method to 
assure lowering of maint2nance costs. Many maintenance 
personnel interviewed about solutions to the OFP maintenance 
problem mentioned OFP rewrite as the best method to show the 
most improvement. 

Rewriting the OFP in either assembly language or 2a 
suitable high order language would allow generaticn of 
currently nonexisting documentation. The A-7 rewrite has 
produced a well documented progran. A significant finding 
of the A-7 rewrite werk was the the importanc2 of a Software 
Requirements Document. Its generation for the A-7 was very 
time consuming. It might be aS important to the maintenance 
function as the modern software engineering principles used 
in the rewritten OFP. The production of documentation ina 
usable form would have significant impact on training of 
system personnel as well as the actual maintenance of the 
program. The documentation could also be designed with the 
eventual use of more extensive and supportive software tools 
tiga 1 Ad. 

The program itself would be placed into a more main- 
tainable state by incorporation of modern software engi- 
neering techniques into the redesigned code. This was the 
ultimate goal of the NRL work on A-?7. It is very easy to 
se2 conversion from the “spaghetti code" that many of tha 
OPPs contain to a modularized format would have great impact 


on the reduction of maintenance costs. The modern version 
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of the OFP would also be easier to test with the reduction 
in the complexity of ths code. The given state of the 
program may be every bit as difficult to detarmine due to 
the complex nature cf the platform and mission of the 
program itself but errors would much easier to isolate once 
detected. 

Several problems do exist in this solution. Costs 
to accomplish 4 rewrite are very high. A complete rewrite 
of the A-6 OFP is estimated by NWC personnel +9 cost upwards 
of 20 million dollars and take four years to complete. The 
finished product would reflect the state of the OFP when the 
rewrite was begun. The ongoing enhancements occuring in the 
operational OFP would still have to be incorporated in the 
rewritten OFP. Meanwhile the existing OFP would have to be 
continually maintained as is currently practiced. The esti- 
mated A-6 OFP rewrite cost represants more money than the 
entire yearly operating budget of the software laboratory at 
NWC. The cost in time and the personnel required to accon- 
plish the project may in fact be the determining factor. 
The perscnnel are not available +t) accomplish the rewrite 
and carry on normal maintenance activities of the opera- 
tional OFP. 

The lifespan of the aircraft in a@ particular modifi- 
cation is subject to change. The days of the A-6E systen 
may be numbered. An F-model is under consideration which 
would represent 2 cecmplete change in many of the systems 
from the E-model. The future of th2 F-model is in the hands 
of Congress. When the F-model will come on line and work 
Slowed on the E-model is unknown. If the funds were avail- 
able to rewrite the A-6E OFP it is hard to imagine them used 
to actually begin recoding work with the possibility of a 
Major avionics and flight software modification arising in 
the A-6F model. 
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Questions remain about the final product of such a 
rewrite. Naval Research Laboratory has not yet completed 
its work on the A-7 OFP rewrite four years after the orig- 
inal completion date has past. If the new OFP will fit the 
available hardware in the aircraft and perform as the old 
OFP, remains to be seen until after testing phases are 
completed. 

For the reasons outlined above, a complete rewrite 
of existing OFPs is not feasible at this time. 


2. High Order Languages 


A rewrite of an OFP is uasually suggested to be 
accomplished in a standard Navy approved high order language 
(HOL). Experience with OFP maintenance by the various soft- 
ware activities has shown that th2 use of a HOL may not 
really be required. NWC personnel estimate that very little 
of the time spent on the maintenance of the OFP is spent in 
actual coding of the maintenance change. Ignoring the soft- 
ware engineering techniques that a true high order language 
affords, very liitle is gained by recoding the OFP. The 
ability to modularize an 2ssembly language version, complet 
With documentation on each module would be as useful. The 
use of a high order language also presents the problem of 
execution speed. The number of syst2ms in use is not high 
enough to warrant spending the funds needed to write opti- 
mizing compilers to insure proper performance of the OFP. 
The use of a high order language would be much more suited 
to a system designed from the start for its use. 

Some interesting ideas aris= from the us2 of HOLs in 
OFPs. While perhaps not suitable for the coding of the 
actual flight system OFPs at this time, HOLS have been used 
in documentation. A HOL version of the OFP is used to help 
the programmer gain a grasp of what the program is actually 
dcing prior to attempting to understand the vary complex 
assembly language version. 
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A recent development is th2 U.S. Air Force decision 
to recode the F-111 OFPs in a HOL. The Air Force plans to 
use Jovial in this conversion. Total costs for the entire 
project which includes conversion of all remaining aircraft 
to digital avionic systems is placed at 1.1 billion dollars. 
Jovial is considered suited well enough for embedded appli- 
cations that the Air Force feels the money required for the 


conversion to a HOL written OFP is worth the expense. 


3. Extensive Environments 


mm mE EE = és = = Se Sa ae 


Another method to improve the maintenance effort of 
a software project is to improve the techniques used in its 
design and implementation. An itprovement in these car 
easily be accomplished through the use of an extensiv2 
programming development and maintenance environment. The 
environment would be used throughout the software lifecycle 
cf the project. This is a fine solution for new systems but 
hardly the answer for mature systems such as A-6 and A-7. 
Cost is the primary problem. Howden [Ref. 6], outlines four 
environments of increasing capablities and costs. The 
highest capabilty reflected in his proposal was designed for 
embedded real time systems. He estimates the capital costs 
ae three million dollars. NADC experience with FASP, 
outlined in the next chapter, sugg2sts that this figure may 
indeed be very low. Costs for the physical environment 
itself do not incorporate the modifications to a program net 
orginally designed for use with that environment. The modi- 
fications required may involve effort equal in cost +0 an 
entire rewrite. 


4G. Adding Hardware 


Personnel not familar with OFP maintenance see the 
hardware as the primary cause of OFP maintenance problems. 


They feel that the maintenance problem can be solved by 
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addition of hardware capability through added memory and 
increased processor speeds. If significant increases in 
memory Space are installed, the program may be able to be 
partitioned and slightly restructured to reduce complexity 
and decrease maintenance costs. While it is well known that 
costs of hardware have dropped significantly with improved 
technology and the costs of software continue to rise, addi- 
tions of large amounts of memory or increased processing 
speed is not the answer to the maintenance problen. 
Physically placing new or additional hardware into the 
aircraft is very difficult and cequires extensive study 
before approval. Due to the long process to research and 
approve changes to the aircraft itself, addition of even a 
small hardware change becomes quit expensive. The older 
aircraft support systems may not be compatible with some of 
the newer hardware technologies randering the addition of 
the new hardware even more difficult and costly. When 
memory additions have been made in the past, many new capa- 
bilities and weapon systems are aided which guickly fiils 
any néwly available memcry space. Merely throwing hardware 
at the problem is not a solution. 
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IV. SOFTWARE ENVIRONMENTS AND FAS 


A. INTRODUCTION 


This chapter will briefly outline the concept of soft- 


Ware environments and review the NADC operated Facility for 


Automated Software Production (FASP), the only current 
attempt at a complete development and maintenance 
environment. 


Be ENVIRONMENT DEFINITION 


The concept of a Software Engineering Development and 
Maintenance Environment is outlined in [Ref. 7]. The envi- 
ronment is generaly defined as the technical and management 
methodologies, the hardware, mode of computer use, automated 
support facilities (tools) and the actual physical work- 
space. It encompasses every aspect of the development and 
support of a software systen. The ideal environment should 
Support a development methodology. Wasserman states that 
this has not generally been the cas® in many past efforts. 
It also should support the software system throughout the 
entire software lifecycle. A specfic definition of the 
lifecycle should be incorporated into the design of the 
environment. The STARS Program Strategy Handbook gives a 
broader definition of an environment to include thse 
personnel assigned to use the environment. 

A complete development and maintenance environmert 
should possess the fcllowing characteristics: 

1. Complete Lifecycle Coverage: The methodology suppcezrted 
by the environment should cover th? entire lifecycle. A 
méans for software system design is followed by a method 
for the code design and implementation. The environment 


ee supports the software system through the maintenanc? 
phase. 
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2. Ease of Transition Between Phases: Hebe Ns Ome ne 
Support of the lifecycle, each phase within the lifecycle 
Should be able to be identified and traversed by nethod- 
Ologies employed by the environment. The transition 
Should be painless and allow the programmer t> move back- 
wards as needed to correct or change earlier work. 


3. Ease of Uses The environment should be designed such 
that the programmer is not burdened by its use. The 
personnel assigned to the project should be able to learn 
e envirdnment's methodologies without undue effort. 
The training of new personnel would be nade easier, 
allowing them to become productive members of the teams 
more quickly. 
4. Repeatability: An ideal environment is general enough 
to be used several times on functionally similar but 
different actual projects. The effort in ¢reating a 
POS environment tailored only to.a specific system 
is lost when that system is no longer in use. 
5. Automated Support: Since the ultimate gqoal of an envi- 
ronment is the increased productivity and quality of the 
product, the selection o the automated suppert facili- 
comes 15 Critical. The tcols selected are, automated to 
the extent that an increase in productivity is gained 
<hrough their use. 

Boehm cites a study in which the COCOMO Model for 
Softwar2 Cost Estimation was used to demonstrate the effec- 
tiveness of the use of a properly designed environment. 
Figure 4.1 shows the estimated improvements in software 
productivity versus software cost driver attributes. From 
the graph presented in Figure 4.1 several of the software 
cost driver attributes can be seen to impact greatly on the 
flight software problem as defined in Chapter Iwo of this 
thesis. Most notably, schedule constraints, turnaround 
time, software tools, storage constraint, required reli- 
ability, program complexity and personnel capability greatly 
influence the maintenance effort of OFPs. Many of these 
factors are out of direct control of the maintenance 
personnel due to the nature of the flight programs and the 
development practices used. It appears from the data 
presented by Boehm that concentration in the areas of 
increasing personnel capability through tools and methodolo- 
., Giles will have the greatest impact 3n increasing maintenance 
\ productivity. Interestingly, testing problems are not 
‘addressed directly by Boehm as a Software Cost Driver 


@ tribute. 
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1.20 Language Experfence 
1.23 Schedule Constraint 
1.23 Data Base Size 

1.32 Turnaround Time 


1.34 Virtual Machine Experfence 
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G. FASP 


FASP (Facility for Automated Software Production) @as 
designed and implemented by NADC in recognition of the high 
costs and complex nature of developing and maintaining 
weapon system software. FASP is currently used in «he main- 
tenance of antisubmarine aircraft software. It was designed 
to be used in the development and maintenance of ary weapon 
software system. Table II gives the Navy standard computers 


TABLE Il 
FASP Language and Compater Support 








Navy Standard Computers 
AYK-14 


UK Y=32 
Navy Standard Programming Languages 


SPL/1 and SPL 
CisS=2M and CA 
MACRO-20 and 
FORTRAN and c 


es) 
NO 


~— I 
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tt 
rN 
| tas 
Cn 


and Navy standard prcgramming languages supported by FASP. 
The total lifecycle of the software system is intended to be 
supported by FASP. It was design2d such that the primary 
development contractors are able to use FASP throughout the 
development process. The maintenance activity is able to 
inherit frem the contractor a complete software systen 
developed on the same support facility it will be maintained 
on. 

Two types of facilities are provided through the FASP 
system. The first is for software integration. Integration 
facilities consist of laboratory simulations of the target 
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aircraft computer systen. The integration facility is used 
in hardware/software integration. It serves as the hardware 
configuration baseline and is also used in the determination 
of the human factors involved in system design and mainte- 
nance. Change proposals to a software system can be quickly 
evaluated by use of the simulated target computers. 

The software production facility, the second facility 
provided by FASP, uses an approach to software development 
in which the same facilities are used for both development 
and maintenance. The software production facility was 
designed to be shared by several software systems for their 
entire lifecycles. Improved software tools provided by FASP 
increase programmer productivity and product quality. 
Management visibility of the software configuration is 
provided. Maintainability is incrsased through the support 
of structured programming and moaularity technigues. 

An integrated database which contains project and 
Management data is ultilized extensively. Maintenance and 
development is divided within the database into distinct 
processes €ach with a measurable output. Input and out put 
of each phase is stored in the database where it is autcmat- 
ically configured into management reports for each project. 
The project manager is able to set production figures into 
the database which FASP will automatically track and report 
on. The configuration control provided by FASP allows mote 
accurate cost estimates on software production. 

Automation provided by FASP reduces the production 
effort in the labor intensive areas of development and main- 
tenance. Increased programmer productivity will offset 
increasing programmer costs by dacreasing computer time 
required in these areas. FASP performs the following auto- 
matic operations: 

1. Translation of simple user sommands int many oper- 
ating system commands 


2. Maintenance of the database. 
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3. Execution of regression testing on specific software 
modules and report cf test results. 


4. Interactive program editing and testing 

These automatic features free the programmer from many 
roucine tasks and allows greater us2 of program librarians. 

FASP provides a formalized structure which contains the 
software tools necessary to increase production and quality 
of the final product. A Software Emulator which simulates 
the target military computer on the FPASP host computer is 
provided. Unit tests of software modules can be performed 
at earlier stages of the development or maintenance process 
in the simulated environment in which it will operate. The 
cost of software errors are reduced by locating and 
correcting them earlier. Testing is also able to begin well 
before the implementation phase. An Automatic Test Analyzer 
determines which paths through the project program have been 
traversed and instruments the sourse code without hindering 
performance. Results are automatically stored in the FASP 
database. From there management reports on path tests are 
generated. FASP also supports Automatic Regression Testing. 
All module test results are maintained in the FASP database. 
Each module has a complete test history available. A change 
to a module will automatically retest all test cases 
affected by the module change and store the results to the 
database. 

Facilities for implementation of FASP are extensive. 
The host system consists of two CDC 6600 and two CDC CYBER 
175 ccmputers. This large capacity system enables several 
projects to be maintained by FASP concurrently. Each 
programmer is able to use a virtual target machine enulated 
by the FASP host computers. Many virtual machines are able 
to be utilized concurrently. By combining the support of 
many projects on one system, significant physical plant cost 
Savings are realized. The large computing capacity is also 
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available to handle urgent maintenance deadlines without 
Significantly reducing normal development and maintenance 
activities. 

FASP allows the use of nearly any computer to tie into 
ies* facilities. Contractors not physically located a+ the 
FASP sight are able to utilize FASP during the development 
phase of the project software. As the maintenance of the 
software is turned over to NADC, 2 smooth transition fron 
the development phase to the maintenance phase is insured. 
The maintenance activity has available extensive documenta- 
tion from development to aid maintsnance. 

FASP is the first attempt at an integrated software 
development and maintenance environnent directed at embedded 
real time computer systems. It has met with considerable 
success on the three flight software systems developed and 
maintained on FASP. Its success is based on the facility 
being used throughout the entire software lifecycle. FASP 
would not be particularly suitable for use in systems in 
late maintenance phases such as A-6 or A-7. These older 
OFPs would require extensive rewrites and documentation 
before the FASP system could be atilized. FASP is best 
suited to be used from the initial development and 
throughout the remainder of the software lifecycle. 
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V. IMPROVING OFP MAINTENANCE THROUGH DOCUMENTATION 


A. INTRODUCTION 


Thus far this thesis has covered the background material 


to understanding the unique problems related to software 


maintenance of real time, embedded aviation software 
systems. Definiticns have been presented and models 
compared. FASP, an environment in use by one’ software 


activity has been presented. The next two chapters of the 
thesis presents tools and methodologies which can be used to 
improve the maintenance effort with modest expenditures in 
time and money. Focus is directed in the two areas where 
the most improvement in the maintenance effort seems 
possible, documentation and testing. Both of these subjects 
were brought up time after time in iicussions with OFP nmain- 
tenance personnel. It is likely when improvements in these 
areas are adopted, cther areas of the problem will show 
improvement also. 

The suggestions presented in th> next two chapters by no 
means offer a quick easy solution. The problem has devel- 
oped over anumber of years ani is much todo complex. 
Solutions will not come easy no matter what price is paid. 
What follows is primarily based on interviews with the main- 
tenance personnel conducted in an informal manner during the 
three trips to the two West Coast Navy flight software 
activities, during ccnferences and over the telephone. 


B. DOCUMENTATION IM EFROVEMENTS 


Every software activity, every person involved in OFP 
Maintenance mentioned one aspect of the OFP software to be 


severely lacking. That area is documentation. In nearly 
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every case the documentation th2 maintenance personnel 
received from the prime contractor when OFPs were turned 
over to Navy was poor. Many of th2 OFP contracts were 
written before any guidance from the Navy was available on 
documentation. In scme flight systems the requirement for 
documentation was left out in order to save initial develop- 
ment funds. The already extremely difficult task of main- 
taining complex OFPs is made nearly impossible by the lack 
of good documentation. 

Because of poor documentation many of the other problems 
of maintaining the OFP software develop. Training new 
personnel is made even harder as it takes a great deal of 
time for somezone to understand a system in which there is 
poor reference material. The new personnel find themselves 
learning primarily through hands on experience. They learn 
the program on the fly as they implement changes. This 
Slows the maintenance effort and affords an opportunity to 
introduce errors into the revised code. 

Poor documentation causes the entire update cycle of the 
OFP to be longer than would be needed with proper documenta- 
zon. Experienced personnel find themselves spending a 
Significant amount of time merely trying to understand the 
existing OFP code prior to designing a maintenance change. 
Because of the effort required to comprehend the existing 
OFP, the larges* portion of time spent in the maintenance 
cycle is spent in the design phase. 

Lack of documentation currently inhibits most mainte- 
Nance teams from uSing many off-the-shelf software tools and 
methodologies. Several personnel interviewed named tocls 
that would help their effort significantly but were unable 
to use due to the difficulty involved in setting up the OFP 
documentation to allow the tools use. Most tools are 
designed to be used with a well documented product. Because 
of this, mcst of the tools used are developed internally and 
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are not able to be shared between different projects. This 
has lead the support systems and methods used by the 
different OFP projects becoming increasingly disjoint over 
the years. Each has become itS own seperate enitity. Laas 
can partly be blamed on poor documentation. 

Difficulty in understanding the code when designing a 
Maintenance change leads to difficulty in determining mean- 
ingful program test requirements for the revised code. A 
poorly designed change du@® toa lack of understanding of 
what the program is suppose to do leads to greater testing 
costs. The number of design errors would decrease if the 
design engineer and programmer had quality documentation 
available. 

Suggestions of what to do first canter on a definition 
or documentation. Documentation is defined in a broad sense 
as the method of giving information about a computer program 
or system so that a reasonably trained person is able to 
understand «the system, use it and nodify it to fullfill new 
objectives. This definition is a modified version of one 
presented by Edmund Berkely [{Ref. 18]. The point taken from 
this definition is documentation allows the person 
utilizing it to understand the systen. 

There are many arguments as to the most effective format 
of documentation. It is an area cf computer science «hat is 
still under extensive study and interfaces directly with 
study of the human learning process. This thesis will cffer 
no profound insights into the proper format of documenta- 
terol. It will accept only the premise that workable docu- 
mentation is critical to the maintenance of OFPs. 

Again citing an active OFP maintenance effort, the A-6E, 
OFP documentation received from Grumman was felt to be 
totally inadequate for the task. It has several major prob- 
lems which limit its use. PLESe, 1% consists only of <he 


OFP program listing anda set of math flow diagrams. The 
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math flow diagrams consist roughly in the format cf crude 
flowcharts containing mathematical representations of what 
is occuring in the program code. They are very difficult to 
read for someone not intimately familar with then. Each 
flow symbkcl contains a large array of cryptic symbols which 
are difficult to follow. The math flows exist on paper and 
have been copied so many times that individual symbols are 
faded and extremely difficult to identify. Changes toa 
program involves converting the representation of the change 
into the math flow format, redrawing by hand the pages 
affected and inserting the change into the hard paper copy. 
This leaves significant opportunties for error. As the 
documentation stands it is totally inadequate for training 
an engineer or programmer. It also does not aliow use of a 
set of capable software tools ina meaningful maintenance 
environment. 

Two very important forms of documentation are missing 
from the A-6 OFP inventory. Current Software Requirements 
and Aircraft Performance Specification Dceccuments are not 
available. The maintenance programmer cannot determine 
exactly what the program is Suppose to do prior to 
attempting to glean how the OFP actually does it. A soft- 
ware redesign is Significantly slow2d by the effort required 
to understand the current progran. Errors are introduced 
only because the redesigned code is not what the maintenance 
change called for. Aircraft performance requirements are 
equally important to determine the parameters involved ina 
redesign effort. They are also inportant in understanding 
Tie Ore Godge itself. Accurate information on what the 
aircraft is doing during certain phases of operation helps 
tell the engineer what is happening inside of the OFP. FOr 
example, what the program expects to see from a certain 
sensor at acertain time is determined from the aircraft 


performance specifications document. 
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The suggestions for improving the documentation do not 
involve a. complete OFP rewrite. The documentation improve- 
ments will center around the OFP as it currently stands. 
These suggestions are aimed at improving the maintenance 


effort without very large expenditures of resources. 


1. Electronic 


Documentatio 


stotage 





The first effort at improvement of the documentation 
would be to change the format on which it is’ kept. 
Automating the storage, retrieval and reducing the time 
involved to record a change would hslp greatly. The chance 
of not incorporating a change to one of the the many copies 
of the paper documentation is reduced. Electronic storage 
also allows the programmer to quickly retrieve the documen- 
tation he requires. 

The A-6 software personnel are taking steps in 
exactly this direction. A Documentation Librarian has been 
hired to deal with the paper documentation and anter it ints 
an electronic storage facility. One person or group of 
persons assigned only to the maint3anance of the documenta- 
te onmwill aliow closer control of the accuracy of that docu- 
mentation. The programmer will not need to burden himself 
with the requirement to enter changes to the documentation 
of code he has revised. 

Many tools abound which would allow the dccumenta- 
tion to be stored electronically. A database could be 
implemented on existing facilities or maintained on an 
expanded small network of microcomputers. The exact tools 
used are not as important as the concept of Maintaining the 
documentation electronically to allow easy access, modifica- 
tion and storage of large amounts of data. 

Characteristics of a systan chosen should reflect 
the following: 
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1. Ease of Use. The system should be easy to use so as 
not to discourage the user. Ideally the system would be 
incorporated online within the system that the programmer 
normally works, | as FASP does. Realistically a stand 
alone machine which does not reguire excessive 2ffort to 
use 1s adeguate. 


Ze Speed 9f Access. The system need not be such that 
1nstanteous access is achieved. Most microcomputer data- 
base systems with adequate menory allow the user to 
access text and print .1t out without a long wait. The 
number of personnel using the system is not large enough 
that concurrent multiple users are a significant problen. 


Be eee Backup. This may se3m incredibly obvious but 
~t must be addressed if the documentation is to be stored 
imean electronic forn. A systen Sel haa beg On a mainframe 
May utilize the operating (system ackup rocedures 
normally used. Snhaller microsystems woul require 
multiple copies be maintained on tape and a procedure to 
insure timely backups implemented. 


4. Consistency., Related to th2_ backup question, consis- 
tency involves a Sa that all copies of the data are 
consistent with each other. This must be accomplished if 
the electronic documentation is to be meaningful. Again, 
the exact system employed to holi the documentation would 

ield the méthod used to maintain consistency. As the 

atabase to contain the current documentation would not 
be extremely large the system t0O maintain consistency 
need not be automated. 


5. Graphical Representation Ca oe Conversion of 
the current documentation woul involve hes es with 
pages copy Which containS many graphical representations 
and symbols. The documentation should not feguire major 
redefinition or restructuring if the cost of maintaining 
it in an electronic. form is *9 be held to. reasonable 
level. The difficulty to use certain symbols contained 
in the math flow diagrams has slowed the effort at 
entering the A-6 documentation into the Xerox Star system 
that they are using. Switching from graphical to text 
modes is constantly required to properly position tne 
symbols required by the math flow documentation. 


The graphical representataion problem may be the key 


to selecting the documentation storage systen. A careful 


survey should be conducted of the data to be entered into 


the new system orior to selecting the storage system to be 


used. The system selected should be able to easily repre- 


sent any symbol raquired in the documentation. Some symbols 


contained in the current documentation may be able to be 


changed to allow the use of a particular storage system. 


This problem may limit the ability to use some of the micro- 


computer databases available. It calls for careful study to 


insure the stored data is accurate and that new data can be 


entered without excessive effort. 
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Costs to implement the elactronic storage cf <the 
documentation vary with the volums to be stored and its 
current hard copy format. Rough estimates of the cost to 
purchase a capable microcomputer system with adequate hard 
disk storage, three to four terminals, adequate graphical 
representation capabilities, backup facilities, software 
(purchased if possible) and printers range from 20,000 up to 
90,000 dcllars. This figure represents a very small invest- 
ment. Once implemented it could provide significant savings 
in the years to come. Cost for more extensive database 


systems to be used on larger conputer facilities range 


higher. The cost of implementing the Xerox Star system for 
storage of A-6 documentation will run approximately 100,000 
dollars. The personnel assigned to use the documentation 
feel that this money is well spent. While input of the 


current documentation is painful, the payoff in the long run 
Will be well worth the initial investment. 

After the system to store and manipulate the docu- 
méntation has been implemented, the next step is to enter 
the documentation required by the lifecycle chart that 
meagre 3.3 Outlined. This would of course involve adapting 
the lifecycle methodology illustrated in figure 3.3 as a 
standard throughout the maintenance process. The documenta- 
tion required at each step is then formated to be entered in 
the storage system after the completion of each phase. A 
documentation history is maintained for each maintenance 
change. The format is fixed and once the maintenance 
personnel become familar with it, lifecycle phase documenta- 
tion generation and usé will becone easier. The systen 
should have enough capacity so that change documentation can 
be stored online between OFP updates to allow easy access if 
required after completion of an update. When the next OFD 
update cycle is started, the documantation is also available 


to help compr2ahend the current state of the OFP. Once a new 
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update cycle is completed the previous update documentation 
is stored in an archival storage system for program history 
purposes. This would enable all change documentation to be 


Maintained in order to be able to trace the OFP change 
history. 


2. software Requirement Documaat 


The next step in improving the documentation of OFPs 
would be the generation of a Software Requirements Document 
(SRD). Work done by the Naval Research Laboratory [Ref. 1], 
yielded a workable Software Requirements Document for the 
A-7 OFP. This document was generated in preparation for 
Becoding of the OFP. The generation of such a document for 
other existing flight systems need not entail recoding the 
OFP. The following outline of the format of the Software 
Requirements Document was modeled from the A-7 work done for 
the Naval Research Laboratory. 

The primary purpose of the Software Requirements 
Document is to describe the externally visible behavior of 


the OFP withsut desribing the implementation. The SRD 


assumes the hardware to be static; this 1s a valid assump- 
tion for embedded aircraft systems. Interface characteris- 
tics are seperated from software requirements. Interface 


characteristics will change only if the hardware changes, 
while softwar2 requirements will change only if the mission 


requirement of the OFP changes. The document is maintained 
as the reference for what the aircraft OFP does. 
Implementation is not addressed. AS an example of what 


might be contained in the document, it might explain that 
during final approach to an aircraft carrier landing, 
certain symbols are displayed on the pilot's heads up 
display (HUD), as opposed to the symbols that are displayed 
during a bombing run. How the computations occur that 


» determine where to place the symbols on the HUD is not 
addressed. 
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AS was done by the NRL work, the format is set up to 
enhance readability and is easily referenced. Tables are 
used extensively to make look up of specific items easy and 
enable the reader to easily spot nissing data. To allow 
table usage, a standard set of definitions which represent 
long phrases or complex conditions are given symbols. They 
are referenced ina data dictionary contained within the 
document. 

The format of the Software Reguirements Document is 
discussed next, it was based on the design of the A-7 


Software Requirements document. 
ae Aircraft Computer 


The A-7 Software Requirements Docunent begins 
With a short discussion of the aircraft's computsr. This 
would be included in any other Software Requirements 
Document generated internally. The distingushing character- 
istics of the aircraft processor are highlighted. This 
section should be written with the newly arrived personnel 
in mind as a primary introduction into the aircraft computer 
system. Detailed descriptions of the computer are currently 
available and do not need to be included here. 


be. Input and Output Data Items 


The purpose of this section is to describe the 
interface between the aircraft processor andthe devices 
which input and receive data from the processor. Input and 
output data are decribed as Data Items. This is the only 
section of the document which contains any information abou* 
the physical representation of ths data. In follow on 
sections of the document, the Data Items and the values 
which they transmit are represented by symbolic names. Each 
Data Item is described in the following manner: 
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1. Each Data Item is pee a symbolic name which is stan- 
dardized throughout the document. 

2. A prose description of its meaning and its relation 
to the device which utilizes it is given. 


3. Numeric Data Items are typed as to accuracy and clef 
requirements. Nonnumeric Data Items are. ga vea the 
mnemomic names cf all possibl2 values whic May be 
aoesrgqned t) it. 


4. The format of the data representation is given. 


Soe The SOC instruction sequence which is required 
to manipluate the Data Item (Read, Transmit, Write, etc) 
1s described. 
Cc. Operation Mode 
P»9ssible states of the program are defined in 
accordance with aircraft operating sc2narios. A precise 
frozen scenario for a Panwrectiasr flaghs profile is 


described. It is very difficult to describe the state of 
the OFP at any given moment without a precise definition of 
what the aircraft is doing at the moment. This concept will 
be shown to critical in describing neaningful OFP tests. 

When possible, modes described by available 
documentation should be used. If wuaavailable, the modes are 
described to match frequently encountered aircraft operating 
conditions. NRL chose five modes to describe: alignment, 
navigation, navigation update, weapon delivery and testing. 
The OFP is able to exist in more than one mode ata time. 
Exclusionary sets are defined to prevent combination of 
modes which are nonsense. The defintion of the operational 
modes should be done in cooperation of the OFP maintenance 
personnel, program simulator personnel, system design 
contractor and a group of experienced fleet users. Once a 
mode is defined and aggreed on, it is set and cannct be 
changed without agreement of the group described abovs. fhe 
definition on the mode would then have to be a careful 
process. 
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Events in aircraft operation which would cause 
the system to switch modes are also described in this 
section. An example would be an event which occurs in 
flight causing the mode to switch from navigation to a navi- 
gational update. This data is represented in table forn. 
Conditions about the state of the program which are defined 
as true for a particular mode ar2 also given in tabular 
form. These conditions are key t5 understanding the state 
of the program during a given mode. 


d. Functions 


The computation of Output Data Items is 
described as one of the many functions that the OFP 
performs. There are many functions involved during an 
executing OFP. Relations between the state of Input Data 
Items and the aircraft operating modes are provided. Thes2 
relations allow the user to determine what coditions of the 
Operating mod= caused an Output Data Item to be produced. 
The operational modes selected in the above section are 
used. No reference is made to clock time. 


e. Timing 


The timing requirements for each function is 
stated in this secticn. An example would be the timing 
tTequirements sf the updates for each display to the aircrew. 
The maximum delay between a request for an Input Data Item 
and the completion of processing yielding the Output Data 
Item is given. If understood, the system reaction to 
exceeding this value should be described. This section will 
be very difficult to complete. In some OFPs, such as A-6, 
the timing requirements between cycles is not static. 
Bounds would have to computed instead of finite values. The 
accurate completion of this section, while difficult, would 


be very valuable for future Maintenance. Timing 
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considerations are pcorly defined and difficult to deal 
with. They are critically important to the accurate opera- 
tion of the OFP. An ability to reference the timing consid- 
erations for each OFP function could in fact be the most 


important aspect of the Software Requirements Document. 


f. Accuracy 


The accuracy requirements for the computation of 
all Output Data Items are given. Phis as another wdifttzeuie 
and important part of the document. The first version of 
the A-7 Software Requirements Documant did not have all of 
the data required to complete this section. It is a common 
complaint of maintenance personnel that they do not know the 
accuracy requirements of the data produced during computa- 
tion by the OFP. Ground and air testing of the OFP may find 
that due to the lack of accuracy information that a function 
delivers incorrect Output Data It3ms causing the OFP to 
perform incorrectly. An example could as drastic as a 
weapon missing a target or the syst@m crashing on uncompu- 
table Input Data Items. 


g. Undesired Events 


Undesired events, such as processing an incor- 
rect Input Data Item, elicit certain behavior from the OFP. 
This behavior is described. The entrance into an undesired 
Situation should be from a standard aircraft operational 
mod2 as described earlier. Input of aircrews should be 
sought to determine the best response, or at least most 
commonly observed response to degraded OFP operation. Thos 
section could quickly grow in size and complexity if every 
combination of device and system failure is considered. A 
bound is set on this section by considering failure of the 
most important functions of the OFP, determined from user 


input and the predefined modes of OFP operation. 
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he Partitioning 


The allowable Pat tierons of the OFP are 
described. Services which are computed by the OFP but are 
not mandatory for aircraft operation or execution of the OPP 
are described. Functions which may be canidates for removal 
at a future time are identified. This is ag sisnporcant 
aspect of the document in that the memory of the flight 
system is more often than not, linitad. Incorporation of 
Significant system enhancements may require the dropping of 
nonrequired functions. This would give the system engineers 
an easy reference to functions not needed. 


i. Glossary 


The glossary defines symbol names and acronyms 


of technical terms used throughout the document. 
j. References 


References used to gather the data contained in 


the SRD and Aircraft Technical Manuals are listed. 
k. Data Dictionary 


The standard terms used in function and Data 


Item description are listed and defined. 


1. Index 


The document is indexed in th2 following manner: 
By Data Item description, Mode description and usage and 
function Output Data Iten. 


The Software Requirements Document is not an 
easy quick fix +o a documentation problem that has existed 
in some OFPs for years. It would not be cheap to implement. 
Perhaps it can be said that it doses not fall within the 


scope of this thesis and offer a solution for the relative 
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short term. Consideration of the expected lifespan of the 
aircraft and the OFP itself must first be weighed prior to 
expending funds for development of such a document. ins 
considered against the long expected lifespan of nearly 
every OFP, development of a workable Software Requirements 
Document is feasible. Before recoding of the OFP could be 
considered, a SRD would have to ba written. Generating a 
SRD yields a document which is useful for current mainte- 
hance work and would be required for possible future OFP 
rewrites. The finished A-7 Software Requirements Document 
while extensive, is a workable document and appears easy to 
follow for someone familar with the terminology of the soft- 
ware it covers. Its format has b2en expressed by mainte- 
nance personnel as suitable for any OFP. 

Generaticn of a good iocument for OFPS which 
currently lack one would be costly in time and money. Tn 
the cases where only a few personnel are familar with the 
entire OFP, their input into the document would be critical. 
It is also obvious that these personnel could not be 
expected to be utilized full time on the generation of the 
SRD without imparing ongoing OFP maintenance. The effort to 
write the document would have to be extended over a period 
of two to three years. The author feels this is not an 
execessive period of time. It sovers approximately the 
production of two OFP updates. A training program could 
also be implemented around the SRD production in which all 
system maintenance personnel are involved. Familarity with 
the function of the OFP would be increased as the document 
was produced. Ultimately the document should be entered, 
stored and maintained on the electronic document storage 
system selected in the first step of documentation 


improvement. 
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3. Aircraft Performance Specification Document 


The A-6 personnel complained about the lack of a 
document which outlined the performance of the aircraft 
itself. A document similar in function to the Software 
Requirements Document for the aircraft is needed in many 
projects. The generation of such a document would not have 
to involve maintenance personnel. It should be contracted 
out to the manufacturer and produceji in a format suitable to 
the maintenance personnel. It also would be very useful as 
a training aid to help the new engineer understand the 
system which he will soon work. If maintained properly it 
would supply the maintenance personnel with an accurate 
definition of the performance profiles of the aircraft which 
directly affect the execution of th2 OFP. A general format 
is proposed. 


ae General Description 


A general description of the aircraft and 
detailed description of th® mission definition are contained 
in the first section. This section mersly provides an 
introduction to the platform and a starting point for under- 
standing the rest of the systen. 


be Mission Profiles 


Mission profiles are defined next. They should, 
as close as possible, match the moje scenarios presented in 
the SRD. Normal values for the various devices which inter- 
face with the flight computer system are contained in 
tabular form. Tables are generated for each flight profile. 
The flight profiles again will impact greatly on the later 
testing phases of revised OFPs. To insure the generation of 
Meaningful test data, the flight profiles are standardized. 
Extreme conditions which are faced under combat situations 


are also represented. 
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Cc. Degraded Operation 


Expected degradations to the aircraft perforn- 
ance are outlined in this section. Battle damage to the 
aircraft which does not render the aircraft unflyable are 
given. The flight software personnel are able to determine 
the expected reduction in device demand and input tc the OFP 
This section should be modeled closely after the Undesired 
Events chapter of the SRD. 


d. Operating Ranges 


Actual specification of the aircraft operating 
parameters are listed. Ranges of possible input and output 
values for the avionics which interfaces with the OFP are 
given. The devices are divided into aircraft subsystems 
such as navigation, HARPOON missile fire control and the 
like. This section serves as a quick reference to the 
actual values of the Input and Output Data Items used in the 
Software Requirements Document. 

The Aircraft Performanc2 Specification Document 
is not nearly as important to the programmer as it is to the 
system engineer. It may in fact allow the programmer to 
cross the boundry between programmer and engineer. it is 
usually available in some form from the manufacturer without 
a great deal of expense being involved. Money should not be 
spent on its development over the Software Requirements 
Document. It is a supplement to the SRD to be developed in 


parallel or after completion of the SRD. 
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Aw. INTRODUCTION 


The very large subject of OFP testing is addressed next. 
Testing of software is not an exact science by any means. 
Debate persists on methods of performing tests to yield 
meaningful and accurate results. Complex software, such as 
the OFPS, present even more difficult questions as to the 
best testing method. The complexity of the OFP presents the 
engineer with a software product that is basically in an 
untestable form. The state of the OFP is difficult to 
erack. Because of this, it is vary difficult to identify 
what conditions triggered a particular test result. Since 
the older OFPs are not modularized, code that requires modi- 
fication is very difficult to isolate. How then can testing 
be structured to assure that meaningful results are 
attained? This is an extremely important question in 
consideration of the OFPs use in high performance aircraft. 
The engineer who certifies an OFP raady for live flight test 
must feel confident in his product. The complexity of the 
cod? must have been addressed during ground tests in order 
that operating conditions in the fleet will not trigger the 
OFP into a failure. The high reliability required of the 
OFP must be obtained during the test phase. 

The testing porticn of the aviation lifecycle has been 
identified as requiring the most resources to accomplish. 
Massive support facilities are required inthe form of 
flight simulators. A great deal of support software is 
required to run Simulations of the DFP. After ground tests, 
the OFP is tested in live flight tests. The live flight 
tests consume a large portion of money due to maintenance of 


the flight range facilities and aircraft fuel requirements. 
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Current test practices in most OFP maintenance facili- 
ties consist of running all or parts of the OFP on the 
camsGet Computer within the confines of a flight simulatcr. 
The simulator is usually written ia a moderately high level 
programming lanuage such as Fortran. It is instrumented to 
attempt to track the state of thea OFP during a test run. 
The Simulator support facility is manned by different 
personnel than the actual OFP maintenance tean. The sinu- 
lator personnel write the support software that is used by 


the maintenance perscnnel to test the OFP. 


Be WEAPON SYSTEM SUPPORT FACILITY 


The simulators fall under the Weapon System Support 
Facility (WSSP) for each OPP. The WSSP is a total system by 
which OFP maintenance is supported to do testing. The WSSF 
serves three primary functions: 

» OFP cee oe and verification. Does the program work 

pioperly and did changes affect the remainder of the 
unchanged code? 


2. New weapon integration. Design of new weapon inter- 
faces with the entire flight software systen. 
oe 


Weapon system analysis. Measurement of simulated 
esults of flight tests and weapon delivery scenarios. 


The WSSF should be structured in an evolving state to be 
constantly improving the support of the OFP. The author 
reviewed the doctrines for the production of support soft- 
ware for the A~7, A~-4&, AV-8 and F-13 OFP projects. All were 
found to be well structured mathoddlogies which conform to 
modern software engineering principles and techniques. 

The subject of OFP testing can be seen to be viewed fron 
two persectives. First the viewpoint of the naintenance 
personnel who need to test the intagration of revised code 
into the entire OFP. The other belongs to the personnel 
assigned to develop and maintain the support facilities. 
The concept of what constitutes a successful test may not be 


75 





the same for each group. One manager of a support facility 
complained the maintenance personnel assigned to the OFP 
which he supported viewed simulator flight testing as a 
"stick and rudder affair." Meaning that the maintenance 
personnel were happy to load the OFP into the test facility 
and execute the OFP in accordance to a poorly defined model 
of the OFP during flight. The test lacked a specific struc- 
ture. He felt this was a misguijied approach to obtain a 
meaningful test of the OFP softwars. 

The WSSF can be thought of as residing between the test 
requirements and the target flight computer systen. The 
role of the WSSF centers around the data supplied to the 
target flight computer system during a test. 

Since the focus of the WSSF is the supply of data to the 
target flight computer, OFP tests must be designed so that 
specific data is supplied to achi2ave a specific test result 
which 1s repeatable. The specific input data can be seen to 
bound the test process. The user and the WSSF should aggree 
on the bounds of the simulation and freeze it from frequent 
changes. The WSSF personnel are able to break the process 
of test procedure software gén2ration into manageable 
modules based on the concrete definition of the test 
requirements. 

The test data design is approached in the foilowing 
manner. The component to be tested is identified and 
isolated. What needs to be tested to validate this compo- 
nent is identified. Once det2rmined, specific test 
scenarios ar=2 designed by the maintenance and WSSF 
personnel. 

The improvement of OFP testing will be centered on the 
tools and methodologies of the WSSF. Development of the 
WSSF is an ongoing process which attempts to constantly 
increase its capability to support the OFP test effort. 
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C. STANDARD FLIGHT TEST SCENARIOS 


The mest important aspect of th2 generation of WSSF 
software which will support OFP testing ina meaningful 
Manner, hinges on standardized flight scenarios. The stan-~ 
dardization of the scenarios attempts to let the maintenarce 
personnel identify a flight profile which will exercise the 
OFP in such a way that realistic meaningful test results are 
obtained. A successful completion of the test flight scen- 
ario would yield flight data whith is recorded into an 
output file. The data recorded is compared to the output 
data expected from this standard scanario. The output file 
and instrumentation data are stored for historical purposes. 

The author witnessed the execution of two test flight 
Scenarios run on the A-4 flight simulator. Ine scenario 
called for the aircraft to take off and execute a climb to 
5,000 feet. From there it flew over a ground target. A 
dive was initiated and several turns were made around the 
target. All of this was represented by simulation of the 
HUD symbols on a CRT Screen. The target was represented by 
a triangle which rotated on th2 screan in accordance to the 
movement of the aircraft. The symbols viewed on the screen 
were generated from the actual signals that the target 
computer generated as it executed the OFP. The WSSF input 
the data which lead the target computer to execute the OFP 
as if the aircraft were actually in flight performing the 
scenario described. The WSSF also provided the interface 
between the target computer and the CRT which allowed the 
HUD simulation. Instrumentation of the input to the 
aircraft avionics from the target computer is recorded by 
the WSSF into an output data file. Timing references are 
recorded to be able to compare the input data with the 
output data. The state of the OFP can hopefully be obtained 
and reasons why specific Output data was generated 
determined. 
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The methodology of freezing the test scenarios is crit- 
ical to the WSSF support software design process. The WSSF 
personnel and the maintenance personnel together decide on 
the scenarios which e¢xercise various functions of the OFP. 
The freezing of the scenario definitions allow the WSSF 
personnel to implement a design process which is modular and 
Can be automated to increase productivity. Scenarios are 
continually built which eventually enable the OFP to be 
exercised in such a way that the tested OFP can leave the 
software facility with a very high level of confidence. 


D. WSSF PRODUCTION TOOLS 


The increasing capability of tha WSSF is critical to the 
reduction of the maintenance effort of the OFP. The produc- 
tion of WSSF software should be automated as much as 
feasible to help provide this increasing capability. The 
WSSF software does not face the storage, hardware support 
and timing constraints that must be considered of the OFP 
itself. The code generated can comply with up to date soft- 
ware engineering principles and use automation when 
possible. 

Automation of the generation of WSSF code also has 
further advantages. The code produced initially is more 
likely to be considered correct. Routine repetitive tasks 
are €liminated, thus increasing productivity. The verifica- 
tion of the simulatcr code integrity 1s made sSimplier. 
Documentation of the simulator cod3 can be made automatic. 
Analysis tools can be built for the test results. 
Portability can be cbtained by using standard automation 
techniques. 

The following software tools, based on the A-4/AV-8 WSSF 
development strategy, are designed around automating the 


production of WSSF software and automating the execution of 
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test scenarios. There are five to0ls mentioned which are 
explained below. The process starts with SREM and continues 
with the Module Generator and FLECS to actually produce 
module code. All three tools work in conjunction to produce 
the module code for software used in the flight simulator. 
The module was defined from the standardized flight 
scenarios covered earlier. AVSIM uses the input data for a 
particular test scenario to execute the modules, required to 
run that test scenario. AVDOC uses data from AVSIM and the 
Module Generator to produce standari forms for documentation 
of a test execution. The first three tools mentioned deal 
with WSSF software mcdule production. The final two tools 
deal with helping to automate the test execution using the 
modules written by the first three tools. 


ilies S EM 


SREM, Software Requirements Engineering Methodology, 
designed by TRW, is a tool which ties requirements to appli- 
Gacions. A Requirement Statement Language (RSL) is used by 
SREM to generate input into the Module Generator (MOG). A 
module is first defined by stating the requirements of the 
module in the SREM RSL. The module definition in the RSL is 
processed and the results are input directly into the Module 
Generator. SREM is written in Pascal and utilizes a rela- 
tional database. The database has the advantage of being 
able to be used with other applications other than SREM. 
SREM is the first tool in automating the production of WSSF 
software. 


2. Module Generator 


The Module Generator takes the output of SREM and 
acts as a FLECS-preprocessor producing FLECS code. FLECS, 
as will be seen, actually produces the module source code. 
MOG structures the application of modular code. MOG 
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addresses only the module input and output. Recent. cal 
dicticnary is used to define modul3s input and output. MOG 
also automatically inserts code into the module which is 
used by another tool to trace, debug and time the module. 


eq Jue 


Fortran Language with Ext2anded Control Structures 
(FLECS) is a tool which acts as a Fortran pre-processor 
generating Fortran 66 code. It has the capability +9 be 
extended to generate Fortran 77 control statements. tise 
takes FLECS code frem the MOG as its input and converts it 
into valid Fortran sourc2 code. It is a stand alone tool 
not tying directly to the MOG. This is the tool which 
yields the portability of the WSSF code. Currenthy “all 
support facilities but one at NWC utilize Fortran 66. Code 
generated by FLECS is tranportable between the facilities. 
FLECS is the last major tool used in the generation of WSSF 
software. The next two tools deal with the execution of a 
test scenario using the software produced by the first three 
tools. | 


4. AVSIM 


AVSIM, Avionics Sinulation, provides an interface 
between the avicnics hardware and the WSSF computer soft- 
ware. It controls the debug, trace and timing options of 
the WSSF code generated by the MOG. The tool is able to 
configure itself in accordance with the data contained in 
the input data file for the test. It is able to turn on the 
WSSF modules required to run a test of the OFP by analysis 
of the test input data file. AVSIM runs the simulation. 
This is an important automatic feature of the test facility. 
Tests are much eéasier to set up and run. Once input data 
for a particular test is standardized, *he output data 
expected by running of the modules AVSIM turns on can be 
standardized also. 
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5. AVDOC 


AVDOC, AVSIM Documentation, generates predefined 
forms from the module generator source files. These forms 
include: status reports, symbol distionary listings, cross 
reference guides and keyword searches of the modules turned 
on by AVSIM in the execution of a test scenario. I+ is able 
to tie directly with the AVSIM and 40G tools. AVDOC can be 
thought of as a book keeping program that expards AVSIM 
information to produce predefined documentation forms. 


6. Example 


After a standardized flight scenario is defined by 
the OFP maintenance and WSSF personnel, it is broken into 
modules. The WSSF personnel take each module and define it 
in terms cf its requirements in the SREM Requirements 
Statement Language. After this is processed, the Module 
Generator structures the input and output of ‘the module in 
FLECS code. MOG also adds code which is used by the simula- 
tion tool, AVSIM, to trace, debug and time the nodule. The 
tool FLECS takes the output of the MOG and produces valid 
Fortran source code for that module. The generation of the 
module is completed. AVSIM is use1 to execute the required 
modules for a particular flight test scenario automatically. 
Which modules are activated are based on the input data file 
for the simulated flight test. Once the first three tocls 
generate the module code, the module may be stored until 
activated by AVSIM. AVSIM also executes the timing, debug- 
ging and trace code during the test execution. AVDOC is 
activated when a test is run to produce staniard forms, 
documenting the test execution. 
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7. WSSF Tool Summary 


These are the primary tools used to automate soft- 
ware production and use at one WSSF at NWC. This method- 
ology <to establish an increasing capability in wWSSP 
development impressed the author 2nough that it was felt 
that a similar approach should be taken on all OFP test 
facilities. Exact tools used will depend on the computer 
resources available. The notion of fixed flight scenarios 
worked out between the Simulator and maintenance personnel 
should be adopted. Until the OFPs are structured properly, 
the biggest payoff in increasing the ability to meaningfully 
test the OFP resides in the WSSF development. 


82 





VII. CONCLUSIONS 


Ae. CONCLUSIONS 


The thesis concludes with several observations and 


recommendations concerning the devalopment and maintenance 
of future flight software systems. 


1. Design Lt Right 


Future OFPs must learn from the mistakes made during 
the development of nearly every current operational OFP. 
While it is not always necessary +t9 design the flight soft- 
ware in a high level language, structuring the code into 
mcdules is crtical to keeping maintenance costs down. The 
hardware system employed should be designed with enough 
Memory and processor capability to handle the first versions 
of the OFP and expected updates without severe loss of code 
structure during optimization. Documentation should be 
produced in accordance with current guidelines. The produc- 
tion of a well designed Software Requirements Document is 
the minimal acceptable documentation. Methods for defining 
interfaces for code developed by different sources need to 
be defined. AS aircraft computer systems become more 
complex, single contractor develop2d OFPs will become rare. 
The interfaces will prevent integration nightmares when the 
Homat DPLOdwet is brought together. 


2. Development/Maint2nance Environments 





Work should continue on environments such as FASP. 


New environments need to be definei to support software for 
future flight systems. Navy flight software activities 
should be allocated funds now to begin develspment of a 
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common development/maintenance environment to be used on all 
flight software. These general purpose environments would 
be defined within guidelines that contractors must follow 
during OFP development. When the Navy flight software 
activities assume maintenance responsibility, the change 
will be smooth and maintenance easier. This recommendation 
will not be cheap to implement, but if the quality cf future 
flight software systems is to remain high the money should 
be spent now. 


3. Money 


More funds should be allocated now to improve the 
Maintenance of operational flight software. As this thesis 
hoped to propose, great ¢xpenditures on the current flight 
software need not be made. When considered against the cost 
of a single aircraft it seems incredible that flight soft- 
ware activities must spend operating funds to deveiop a very 
badly needed Software Requirements Document. The generation 
of a SRD is not expensive when th2 savings it will generate 
over the 'remainer of the OFP lifecycle are recognized. 


4. Education 


Two recommendations concerning education are made. 
The first centers around the personnel who make decisions on 
Meranitesottwdre contracts and fund allocation. From the 
observations made by the author during research for this 
thesis, it was felt that past high level administrators of 
flight scftware funds and contracts knew nothing about soft- 
ware at all. One manager of an OFP maintenance team relayed 
the stcry of a high level administrator located well above 
the trenches asking him how much did the flight software for 
a particular aircraft weigh. He nesded to know this in 
order to allocate funds concerning that software. When this 


type of knowledge level is faced from those who control 
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funds for software development and maintenance it is easy to 
see why some of the errors made? in the past were committed. 
Personnel who understand the natur2 of real time embedded 
software and the general principles of software engineering 
should be placed in mcre responsibl2 positions. 

The second aspect of education revolves around 
training new engineers for emplcyment in the flight software 
laboratory. No facilities exist for training an engineer on 
a system such as A-6 or F-14. The Navy should begin a 
program where engineers are identified in the academic 
institutions, sponsored and trained in engineering and 
computer courses which would most help in working on flight 
computer systems. This person would then obligate to work 


for the Navy for a minimum length of time. 


Be FINAL CONCLUSIONS 


All cf the recommendations mad2 in this thesis present 
difficult decisions concerning expenditures of funds for 
aviation flight software maintenancs. There are those who 
feel that th2 expenditure of these funds are not needed. 
The fact remains that if the high quality of Naval flight 
software is to continue, these difficult decisions must be 


made and the money spent. 
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